Option _Explicit Keyword(s) of day XXX:

[SMcNeill]

@Dimster I understand what you're saying perfectly.  In fact, I tend to think the same way a lot of times:  Stupid OPTION _EXPLICIT!  Nothing is any more annoying than having to scroll back 500 lines of code to get back to the declaration area of your source/routine, just to add a little DIM x, y into the code to create a couple of simple loops.

I tend to enjoy programming in a constant flow, when the creative juices are all working properly.  My brain is quickly moving forward with:  Let's do this, and then this, and then onto this, and in the end we'll accomplish this!  Having to stop, back up, and then scroll to the beginning and add in a DIM statement interrupts that flow of indeas for me, makes me lose track of what the heck I was trying to accomplish, and takes me "out of the zone" for productive programming.  It's the same way when I tend to work on one of my novels -- I let the creative juices flow, write the whole thing uninterrupted, and on AFTERWARDS do I ever think about going back and editing and proofreading.  Once I get in the flow, I don't want to break that for anything -- much less just to DIM a temp variable!!

So what's the simple solution?  Add the following to the start of your code:

Code: (Select All)

DIM a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z

There ya go!  All simple variables explicitly defined -- whether you actually make use of them or not -- and ready to go anywhere in your code.  Option _Explicit won't complain over them not being defined, and I won't get any errors anymore when you use them.   Since you didn't define them as any specific type, they're going to be the same DEFAULT type as if you just added them into your code without that single line of definition.

FOR x = 1 TO 10    <-- Without any DIM statement in your code, x would default to be a SINGLE type.

FOR x = 1 TO 10    <-- With the DIM statement we used above, x would still default to be a SINGLE type, as we didn't specify it as anything different.

Add that one single line to start of your program (and/or subs/functions to keep it limited in scope) and then Option _Explicit won't complain over those temporary control variables.  

It's really not that much to add, while allowing for the useful error prevention that Option _Explicit can help add into your coding toolbox. 

[mnrvovrfc]

If there were no such thing as QB64, but Freebasic existed until today as actually, many people would give up BASIC programming for good.

What happened to the old days of Fortran in which some variables had types the programmer couldn't choose? Such as "i" being an integer to be used as counter? I don't know for sure but I think 1/3 of single-letter variables were left as one type, another third of a different type and another third... maybe for strings.

Csound is like this too: variables have to start with a specific letter to type them such as "a" for audio vector, "k" for control-rate counter. In front of that add "g" if it's a global variable such as "ga" being an audio vector recognized by all instrument definitions found in the CSD code.

This was reflected somewhat in Win API programming such as "lpzstr" used at first in a variable name to indicate a pointer to a string sequence that ends with ASCII0. C/C++ didn't require it but it was part of the documentation away from MSDN.

I'm using OPTION _EXPLICIT even though I don't have to because I need more excitement in my life. I was supposed to go ahead with my project for a simple music sequencer which employs a pair of text file information and wave data, to set up loop points, amplitude envelopes and stuff like that. Also I haven't forgotten that game using the robot and monster sprites created by JDJ...

[mnrvovrfc]

Once the loop is finished the control variable carries a value of Loop Limit +1. 

If I do not DIM a control variable or I avoid using Option _ Explicit 
 - I'm in less danger of an unexpected value to the control variable.

I hope you never use STEP in the same line as FOR in your programs because that statement of "loop is finished" isn't always true.

OPTION _EXPLICIT has nothing to do with a loop variable being changed without being expected. If a loop variable isn't going how it's expected for FOR... NEXT then there is bad code between those two keywords.

A lot of people are getting by with single-precision variables as FOR... NEXT control variables because they hate that much to use OPTION _EXPLICIT and/or to use DIM to make sure the variables are integers. That's OK with me by this time. But otherwise please investigate the code that goes on inside the loop -- be careful with anything assigned to the variable related to FOR.

Code: (Select All)

FOR x = 1 to 10
  x = computesomethingcomplex() '<-- be careful with a rogue line like this! The "FOR" should be the only one with "x is assigned".
  '(rest of loop)
NEXT

Try not to use colons excessively to cut down on lines of code which makes code difficult to read and makes it harder to look for such rogue assignments.

I just thought of something else. Be careful also with something like this:

Code: (Select All)

DIM AS INTEGER x, y

FOR x = 1 to 10
  callsomething x, y
  PRINT x
NEXT

SUB callsomething (x as integer, y as integer)
  x = y * 2
END SUB

Note that I have used DIM for "x" and "y" to better match the SUB definition. It's possible for the loop control variable to be sent as parameter to a SUB or FUNCTION, which could get changed by the subprogram.

We need to build a serious debugger for you.

[bplus]

What happened to the old days of Fortran in which some variables had types the programmer couldn't choose? Such as "i" being an integer to be used as counter? I don't know for sure but I think 1/3 of single-letter variables were left as one type, another third of a different type and another third... maybe for strings.

Nutt'n happened, you can decide which you want to type whatever way you want. What could be more flexible than that?

@mnrvovrfc check this out:

Code: (Select All)

DefInt I

a = 1.1

b = 2.2

c = 3.3

i = 4.4

i6 = 5.5

iTen = 9.9

Print a, b, c, i, i6, iTen

[Kernelpanic]

@Terry -  Correct. If OPTION _EXPLICIT were the first line of code in the example, the variable mm would have been flagged immediately. Also, a constant is not an ordinary variable. A constant can't have its value changed once set. The IDE will flag this if you try it:

Ordinary variable is probably worded a bit imprecisely, but by now one should know what I mean: Without Option Explicit there is no guarantee that a constant variable will be changed by a typo. This can really be a very nasty bug in a larger program - until you find it.

[Kernelpanic]

@bplus -  As you can plainly see the IDE ain't buying your blunder!

@KernelPanic that's it from me for you on this subject.

OK!

[SMcNeill]

@Terry -  Correct. If OPTION _EXPLICIT were the first line of code in the example, the variable mm would have been flagged immediately. Also, a constant is not an ordinary variable. A constant can't have its value changed once set. The IDE will flag this if you try it:

Ordinary variable is probably worded a bit imprecisely, but by now one should know what I mean: Without Option Explicit there is no guarantee that a constant variable will be changed by a typo. This can really be a very nasty bug in a larger program - until you find it.

Once a CONST is set, it remains constant -- it can't be changed.  There's nothing to stop you from making a typo and misspelling the CONST (cheetos instead of cheetoes), but the CONST, as defined, won't change once it's set.

[TerryRitchie]

@Terry -  Correct. If OPTION _EXPLICIT were the first line of code in the example, the variable mm would have been flagged immediately. Also, a constant is not an ordinary variable. A constant can't have its value changed once set. The IDE will flag this if you try it:

Ordinary variable is probably worded a bit imprecisely, but by now one should know what I mean: Without Option Explicit there is no guarantee that a constant variable will be changed by a typo. This can really be a very nasty bug in a larger program - until you find it.

Ah, OK, I read your statement wrong. You are advocating for the use of OPTION _EXPLICIT to avoid this from happening, gotcha.

Something I used to do before OPTION _EXPLICIT existed in QB64 was to always capitalize every letter in constants except for the first letter which was always a lower case c. This way if I mistyped a constant the IDE would not capitalize it letting me know I misspelled it.

CONST cONEDEGREE = .017453292

<code>
<code>
Xrotate = Xrotate + condegree ' won't capitalize because of misspelling

[bplus]

I like using Camel style and mod all globals: Shared, Const, Subs and Functions, names start with capital letter and all locals use lower case for first letter. Then when I type all lower case good ole IDE corrects for caps if it recognizes the variable, no correction means look for error. Local variables should usually be in sight of where you are at in code.

So another way to get along without Option _Explicit.

[Dimster]

Here is one more example of a difficulty I have run into with Option _Explicit, and it has to do with Local variables v's Global or Dim v's Dim Shared I know the fix is just Dim Shared every variable but keeping with the theme of the use of a "throw away variable" as in a counter situation, it also pops up with Locally declared variables. With Option _Explicit you pretty well need to give up on a locally declared variable.

Code: (Select All)

'Option _Explicit

Dim Shared x
Dim x1

'Main Module
x = 1
x1 = 100
Print "Main Module values"
Print " Value of x = "; x
Print "Value of x 1 = "; x1
Print "Value of x2 = "; x2
Print "Value of x3 = "; x3
Print

Subx2
Subx3





Sub Subx2
    Dim x2
    x2 = 200
    Print
    Print "Subx2 Module values"
    Print " Value of x = "; x
    Print "Value of x 1 = "; x1
    Print "Value of x2 = "; x2
    Print "Value of x3 = "; x3
    Print
End Sub



Sub Subx3
    Dim x3
    x3 = 300
    Print
    Print "Subx3 Module values"
    Print " Value of x = "; x
    Print "Value of x 1 = "; x1
    Print "Value of x2 = "; x2
    Print "Value of x3 = "; x3
    Print
End Sub

Without Option _Explicit all the variable values work as expected.

For me personally, I think all my objections to Option _Explicit are simply a resistance to change which is not a good trait in a modern day programmer/coder. The thing is that Option _Explicit does an excellent job in catching misspelled variables which are very much an issue I have and a time waster to track down. So how difficult is it really for me to declare all variables as Dim Shared along with adding Option _Explicit at the beginning of all my code. It's a lot less time than trying to track down that one misspelled variable. Thus I morn the loss of the throw away local variable. Excellent excuse for another beer.