PureBasic Forums - English

gomio,

Your tip is good by the way. It's pissing when inserting in old code but it makes necessary to define types of any variable.

BTW, I agree an explicit option. I wrote big apps in the past where nothing would have work with no obligation to be careful about types.

The largest code I have in Purebasic is under 5.000 lines, but it is already big enough to have some surprise to maintain the code.

Rgrds

Ok for me, as long as it's strictly optional (I love bug hunting/I hate declaring variables).

El Choni,

I code as you do it seems. Do what I say but not what I do ...

Rgrds

hehe.

Agree that forcing declarations is good.

Also agree with the optional bit, eg a compiler directive like Option Explicit.

Dare2 wrote:hehe.

Agree that forcing declarations is good.

Also agree with the optional bit, eg a compiler directive like Option Explicit.

Yes. I mean an 'optional' Option Explicit... Like VB ..

- np

I'd like to see an optional explicit type command also. My fingers are always accidently hitting the wrong keys when typing in variables. My latest trick is to forget the # on constants, and then spend a while scratching my head wondering why everything is breaking.

aaron wrote:My latest trick is to forget the # on constants

gomio, your trick does not work here

x.l

For x=1 To 10
x=c+1
Next

c is undeclared.

i hope Fred add this sometime. it makes PB an invalid tool for big projects in my opinion.

PureBasic should have something like Visual Basic's "Option Explicit".

deadmoap wrote:PureBasic should have something like Visual Basic's "Option Explicit".

The solution, if the compiler directive was set.. 'Option Explicit'
Or in this case.. Purely Explicit ..

Use a "Two-Pass" compiler ..

- np

lol, I like PurelyExplicit. Or maybe use PureAgony if no type checking is to be done (typecheck is default).

A quick and dirty way would be to build a couple of lists, one holding each unique variable name when encountered, one for declares, as PROCNAME:VARIABLE.TYPE:flag

eg, declare list:
[MAIN]:a.l:global
[MAIN]:s.s:global
[MAIN]:k.l:local
myProc:w.l:local

and found list:
[MAIN]:a.l
etc

Then at the end of compilation process, ensure that everything in the found list is also in the declare list. Throw an error if not. For proc vars, throw if not found or equiv [MAIN]xx:global not found.

And throw an error if PROC:VAR already exists when building declare list.

I think MS scripting must do something like this as you can DIM almost anywhere (within scope) even after a variable is used.

This is a more universal issue than addressed. For instance, the scope of a variable, whether global or local, also is a factor to consider. Many variable names are reused locally, with the understanding that what happens inside a prodedure remains inside that procedure. But procedures permit global references as well, and you may inadvertently be using a global variable as though a local one by mistake - a very hard problem to find in its own right.

I agree that having this as an option is a good thing, but its use would again vary by source code. Certain programs might need it, and others might not. I don't think this would work well as a command line option,
but needs to be controlled by a software switch within the source code itself, controlled by a statement of some sort.

Another option might be to turn it on in the IDE, so that every variable that was not predefined will be presented in bold face or with an underscore, or perhaps a different color, or in itallics. The idea being that it would immediately stand out. Of course this feature would not work until after the program has been compiled and run at least once, and then only if the compiler has some way to let the IDE know what variables were defined on-the-fly. But it would be a great debugging tool.