Why use Local and Global at all?

[WRP]

A variable declared within a function is automatically Local. Anything declared outside a function is automatically Global, even if it was declared Local, since there is no file scope. As for declaring Global within a function, that's just a bad idea. So is there really any benefit to having the Local/Global declarations?

 

[Melba23]

WRP,

I believe so - declaring the scope implicitly makes sure that the coder fully realises the scope for that particular variable/constant.

M23

[WRP]

I have tried writing scripts without Local/Global and everything seems to work fine. I would expect there to be problem situations, though, since the single equals sign is overloaded as both assignment and test. Can you think of example cases where omitting Local/Global would break the code?

[jchd]

Plenty!

[czardas]

To prevent crude, unsophisticated and extremely limited functionality; we use scoping. The following is a crude demonstration of a local / global collision. Sure it's possible to write code like this, but once you start working on larger projects you don't want to have to keep tabs on all the possible collisions.

$i = 0
ConsoleWrite(blah(blah(blah(''))) & $i & @LF)

Func blah($_)
    $i = 1
EndFunc

The best way to avoid collisions is to always try to use local variables. Sometimes achieving this can present a bit of a challenge; but it's a very flexible, and certainly the safest, approach. So now we can write this:

Local $i = 0
ConsoleWrite(blah(blah(blah(''))) & $i & @LF)

Func blah($_)
    Local $i = 1
EndFunc

Both the variable declarations in the above example are correct, but there is a potential problem. The first (local) declaration of $i produces a global variable by default, because it was not declared within the function blah(). The second declaration produces a local variable because it was declared as a local variable within the function blah(). To ease the mind (but not necessarily the conscience), we can make the code easier to understand by being more explicit and use the keyword Global for the first declaration. Doing so doesn't change the outcome or reduce the risk of a collision.

Global $i = 0
ConsoleWrite(blah(blah(blah(''))) & $i & @LF)

Func blah($_)
    Local $i = 1
EndFunc

The above code is not a good example because it is quite meaningless and does not actually need to use any variables at all.

ConsoleWrite(blah(blah(blah(''))) & 0 & @LF)

Func blah($_)
EndFunc

 

---

So why use global variables?

One example of good usage is when you want to share data between several scripts (and other developers). Perhaps the data is a constant like Pi: two letters being easier to remember than a larger number of digits. In all cases, using global variables runs the risk of encountering collisions. Using long and unusual variable names reduces the likelihood of a collision but makes the code harder to read. All considerations / trade-offs need to be kept in perspective. Explicitly declaring local variables within functions prevents collisions, which I assume is the main objective.

Edited April 3, 2016 by czardas

[philkryder]

does anyone use g,p, and l to distinguish and avoid collisions?

$igCounter  for a global integer variable

$ilCounter for a local integer

$ipCounter for a parameter?

 

[czardas]

Take a look here: https://www.autoitscript.com/wiki/Best_coding_practices#Scopes_of_Variables

[RTFC]

13 hours ago, WRP said:

Anything declared outside a function is automatically Global, even if it was declared Local, since there is no file scope.

There's a caveat to this (incidentally, one that is not mentioned in that Best coding practices that czardas just linked to), in that a For variable inside a function with the same name as an existing global variable is treated as a different, purely local variable. This will be more obvious when explicitly (re)declared. Example:

Global $myGlobalVar=123
Consolewrite("value before call " & $myGlobalVar & @CRLF)
_MyFunc()
Consolewrite("value after call " & $myGlobalVar & @CRLF)

Func _MyFunc()
    ;Global $myGlobalVar    ; even if explicitly declared as global here, it's still redeclared local by For
    For $myGlobalVar=1 to 3
        consolewrite("value in func " & $myGlobalVar & @CRLF)
    Next
EndFunc

So usage of For <var>=x to y inside a function also makes that var Local, even if it has previously been declared as having global scope, and even if it is redeclared as Global inside that function beforehand. I ran into this when I tried to use a For loop inside a function to try and adjust a global variable's value, which turned out to be a terrible idea. So all the more reason to always explicitly declare, if only to keep conscious track of scope (and make the code easier to read for your future self, and others).

Edited April 3, 2016 by RTFC

[czardas]

@RTFC LOL, just imagine if a local loop iteration count (within a function) was able to corrupt a global variable in that way: total nightmare. 

Edited April 3, 2016 by czardas

[RTFC]

@czardas: Yeah, it wasn't a particularly bright design concept on my part, I agree. But I figured that an explicit global declaration in <main> would always trump any explicitly undeclared var's scope inside a func. My bad, of course.

Edited April 3, 2016 by RTFC

[czardas]

Just to let you know, I tested it too  and was quite relieved after confirming the true behaviour.

Edited April 3, 2016 by czardas

[RTFC]

The Help file text of the For statement does mention it, but of course I didn't read up on it, I just tried and watched it fail horrendously. And not having explicitly declared the var local in the func, I assumed it would remain Global there (NOT). I'm just glad I don't work for NASA...

[WRP]

11 hours ago, czardas said:

Explicitly declaring local variables within functions prevents collisions...

I understand the argument of using Local/Global for code readability, but I don't see it for avoiding collisions.

As far as I can tell, except for the case of Global within a function, AutoIt assigns the same scope to variables whether or not Local/Global is used. So, Local should have absolutely no effect wherever it is used.

[trancexx]

26 minutes ago, WRP said:

I understand the argument of using Local/Global for code readability, but I don't see it for avoiding collisions.

As far as I can tell, except for the case of Global within a function, AutoIt assigns the same scope to variables whether or not Local/Global is used. So, Local should have absolutely no effect wherever it is used.

Is it hard for you to imagine something like this?

$i = 5

SomeFunction()

MsgBox(4096, "Aha", "$i = " & $i)



Func SomeFunction()
    $i = 4096
    $y = 2

    MsgBox($i, "...", "wait a bit", $y)
EndFunc

Try adding "Local" for variables inside the function to see if there'd be any changes.

Anyway, variables used only inside a function should be declared as local, not because of readability, but because of correctness. czardas already explained.

Edited April 3, 2016 by trancexx

[WRP]

OK, so the explanation I needed is that without Local/Global, the default behavior is to make a variable declared within a function local UNLESS the name refers to an existing global variable. So the use of Local prevents reference to an existing global variable.

 

[BrewManNH]

That is correct, and is explained in the help file.

[philkryder]

1 hour ago, WRP said:

OK, so the explanation I needed is that without Local/Global, the default behavior is to make a variable declared within a function local UNLESS the name refers to an existing global variable. So the use of Local prevents reference to an existing global variable.

 

If one uses the best practice of having a "g" in the name of global variables, then, collisions would not happen.

[philkryder]

14 hours ago, czardas said:

Take a look here: https://www.autoitscript.com/wiki/Best_coding_practices#Scopes_of_Variables

thanks - 

Is there any interest in including a recommendation to use the "p" for parameters?
They are different from local variables in the that they can be changed and cause a side effect change back in the calling function or mainline code.

[czardas]

2 hours ago, philkryder said:

thanks - 

Is there any interest in including a recommendation to use the "p" for parameters?

Parameters are treated as local variables unless you use the ByRef keyword, so function parameters do not collide with global variables. Remove ByRef from the code below and the global variable will remain zero. Also, scroll up the best coding practices page and you will see that the letter p is already used to indicate a pointer.

Global $g_iParam = 0

Go($g_iParam)
MsgBox(0, "", $g_iParam)

Func Go(ByRef $g_iParam) ; Remove ByRef to test the difference.
    $g_iParam = 1
EndFunc

 

Edited April 4, 2016 by czardas

[guinness]

16 hours ago, philkryder said:

Is there any interest in including a recommendation to use the "p" for parameters?

No, as p already has a meaning