Give me example where Dim differs from Global

[Coded4Decades]

Can anybody give me an example where switching 'Dim' to 'Global' actually makes a difference?

I have been using global variables and local variables in other languages for decades without any trouble.

But, autoit's distinction between Global and Dim leaves me quite confused. The help files and many forum posts say that Dim is different from Global.

But, I can't find any simple example where it actually makes a difference.  For instance, I've tried many permutations of Dim and Global in the following program and have not been able to find any difference.

dim $i = 10
Global $msg
s1()
s2()
s3()
$i = $i+9000
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'final='&$I & $msg) ;### Debug MSGBOX
func s1()
    local $i
    $i=$i+1
    $msg = $msg & @crlf & "$I="&$i
endfunc
func s2()
    dim $i
    $i=$i+1
    $msg = $msg & @crlf & "$I="&$i
endfunc
func s3()
    dim $i
    $i=$i+1
    $msg = $msg & @crlf & "$I="&$i
endfunc

[Coded4Decades]

Global $msg
s3()  ;s3 creates $i as local variable, then throws it away at endfunc
s1()  ; s1 changes creates $i as a Global variable and it continues to be global
s2()
dim $i ;seq execution 4
$i = $i+9000
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'final='&$I & $msg) ;### Debug MSGBOX
func s1()
    global $i ;seq execution 2
    $i=$i+1
    $msg = $msg & @crlf & "$I="&$i
endfunc
func s2()
    dim $i ;seq execution 3
    $i=$i+1
    $msg = $msg & @crlf & "$I="&$i
endfunc
func s3()
    dim $i ;seq execution 1
    $i=$i+1
    $msg = $msg & @crlf & "$I="&$i
endfunc

Actually, I may be figuring it out myself.  Each time autoit sees a Dim xxx Global xxx or local xxx it checks if xxx for previous usage.  This is done in the sequence of execution, NOT the way the code is listed in the source file.

local (variable) is treated

   case variable not allocated then allocate it as local

   case variable already allocated as local then use that allocation

   case variable already allocated as global then

      create a new global allocation and use it

Dim (variable) is treated as

   case variable not allocated then allocated it as local

   case variable already allocated as local then use that allocation

   case variable already allocated as global then use that allocation

Global (variable) is treated as follows

   case variable not allocated then allocate it as global

   case variable already allocated as global then use that allocation

   case variable already allocated as local then

      create a new global allocation and use it

Endfunc is treated as follows

   Every Local variable is deallocated

   Every Global variable is retained.

Edited February 2, 2014 by Coded4Decades

[Melba23]

Coded4Decades,

Welcome to the AutoIt forum.

Might I suggest the Variables - using Global, Local, Static and ByRef tutorial in the Wiki?

Basically Dim sets the scope automatically depending on whether you are in a function (Local) or not (Global). It is much better practice to explicitly set the scope using the correct keyword.

M23

[jchd]

Nowadays and AFAIK, Dim has only one use: allow for dimensionning an array in a function where it is passed as ByRef parameter, and when you aren't sure it actually is an array with required dimensions.

This is the only situation where Dim should be used, other scope specifiers being the norm elsewhere.

Global $a, $b[4]

f1($a)
ConsoleWrite(VarGetType($a) & @LF)  ; $a is now a Global array

f2($b)
ConsoleWrite(VarGetType($b) & @LF)  ; no need for Dim in f2 to make the parameter a flat variable

f3()


Func f1(ByRef $v)
    Dim $v[3] = [4, 15, 9]
EndFunc

Func f2(ByRef $v)
    $v = 123    ; assignment destroys what $v was before
EndFunc

Func f3()
    Local $x
    f1($x)      ; here Dim in f1 keeps $x as local
    ConsoleWrite($x[1] & @LF)
EndFunc

[guinness]

Nowadays and AFAIK, Dim has only one use: allow for dimensionning an array in a function where it is passed as ByRef parameter, and when you aren't sure it actually is an array with required dimensions.

That's the only use I have seen for it as well.

[Coded4Decades]

I promise, all future coding will avoid Dim.  Unfortunately, I have inherited an important program that was developed over a 4 year period. In the first year he always used Dim statements. He eventually changed to local/global but did not change the original code.

Naturally, most of the DIMed variables should have been Local but many of them should have been "Global"

Because of this, simply changing all "Dim " to "Local " causes compile errors. Changing a handful of Locals into Globals got rid of most of them, but some of them seemed to require resequencing the code.

That is when I started to get nervous.  In my many years of painful errors, I have learned not to "fix" someone else's bad practices (or my own!) without thoroughly understanding what is going on.

Since most of the people at this forum do not use a bad practice, I doubt if there will be much help with the subtle stuff that will go wrong. So, I will shortly close this problem with just one last question. Why the heck does Local in the main program get treated as Global? And, does this mean it is "best" practice to put the main program AFTER the functions?

Opt("MustDeclareVars", 1)
local $Problems
test()
Exit
func test()
    local $Problem
    $problem = "what if i "
    $problem = $problems & "spelled my variable wrong?"
    $problem = $problem &"How can I force a compile error?"
    MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'Selection:' & @CRLF & '$problem' & @CRLF & @CRLF & 'Return:' & @CRLF & $problem) ;### Debug MSGBOX
endfunc

Edited February 2, 2014 by Coded4Decades

[Melba23]

Coded4Decades,

 

I promise, all future coding will avoid Dim

Good plan.

Turning to your questions

- 1. As I mentioned above, AutoIt has an automatic scoping mechanism. You might well have declared $Problems as Local, but AutoIt treats it as Global as it is outside a function declaration. This has caused a lot of angst on the forum over the years between those who consider this confusing (among which I count myself) and others who believe that the variable should be regarded as Local to the main script (even though it is actually treated as Global). To my mind this is complete nonsense - even if it might well be true in other languages it is demonstrably not so in AutoIt and as a result can only cause confusion as you have just proved once again. Alas, the Help file is stuffed full of Local variables that are actually Global because of this ludicrous idea that we should "teach good scoping practice" even when it is self-evidently not applicable to the language we are actually using. But other than in my own scripts I gave up on that argument a long time ago.

- 2 . I would suggest "best practice" is to have the main script before all functions - my personal sequence is as follows:

directives
#include files
Opts
Global declarations
HotKeys
Ini reading
Main script
Message registering
Main idle loop
Functions

Obviously some parts may need to be after others so that the data is available , but in principle that sequence works well.

I hope all that is clear - please ask again if not.

M23

[Coded4Decades]

Despite to many decades of programming, I am new to autoit so am reluctant to get on a soap box.  Nonetheless, I still want to practice good scoping.

But, that is hard in a language that treats every Local variable in the main program as if it were Global.

It just seems to me that for NEW programs, the following layout seems to be much better

:

system library includes and perhaps some of my own includes

global variables  (the real ones)

functions

; ; ------ main program ------This comment and ctrl F makes it easy to edit the main code--

local variables

main code with my own includes sprinkled where appropriate

The advantage of that sequence is SAFETY--  I don't have to worry about a fat finger error buried somewhere within a dozen functions accidentally hitting a main program's local variable. 

I only see two disadvantages

#1 I have to skip past the functions when editting a program.

#2  when a global variables takes a bunch of code to initialize, it is distracting to have to go to the top of the program to insert the Declaration.  

Both disadvantages seem to be very minor. Yet virtually every code sample I see  puts the code at the top. What am I missing?

Of course, the above only applies to new programs.  The legacy program I am changing needs to  be handled with kid gloves, so I will leave the old code at the top.

[guinness]

I quite agree that it causes confusion with Local outside of a function being treated as Global, as it should be Local to the scope, so only accessible in that space. That being said, my opinion still remains the same that if you use a variable only in that space (and not inside functions) then it should be declared as Local. Why? Because you can clearly see when reading the code that the particular variable isn't buried deep inside a function somewhere.

[mikell]

Melba,

The includes are placed at the top and they contain functions, then placing the custom funcs at the bottom of the script seems a good practice mainly concerning readability

[Melba23]

Coded4Decades,

I have been coding for over 40 years too, so you are not the only greybeard around here.

My way of trying to make sure I do not make typo errors is to carefully name the variables. A basic form of Hungarian notation to define the type (given that AutoIt does not type its own variables) - so $a for arrays, $s for strings, etc - plus an added prefix for Global variables (either an added $g_ or an abbreviation of some sort ($EMB_). Look at some of the UDFS in my sig to see how I have done it in the past.

One thing to remember is that you can use really complex variable names in the script and then use one of the tools in the full SciTE4AutoIt3 editor suite (you do use that I hope?) to replace these with shorter names when compiling so as to speed up execution. The tool is currently known as Obfuscator, but will soon be replaced by another tool with similar functionality which some of us are beta-testing at the moment.

One final point:

main code with my own includes sprinkled where appropriate

#include means that the full text of that file is inserted at that point - so be careful with including files in the middle of code, you may not get exactly what you intend.

M23

Edited February 2, 2014 by Melba23
Fixed BB tags

[Melba23]

mikell,

 

placing the custom funcs at the bottom of the script seems a good practice mainly concerning readability

Quite so. But remember that the includes are self-contained and take but a single line whereas custom functions for the particular script often need to be expanded. The sequence of sections is, as I mentioned, a personal decision and the one I suggested above is my personal preferred layout and not by any means an obligatory template for others.

M23

[guinness]

I pretty much have the same layout as Melba23.

[mikell]

So do I (and I will keep going) but specify the real reason is not pointless

[Coded4Decades]

To bad there isn't an option to resolve this issue.

Something like opt("TreatLocalAsGlobal",0).

Anyway, here is the current disadvantages of putting the code at the bottom

#1 I have to skip past the functions when editting a program.

#2  when a global variables takes a bunch of code to initialize, it is distracting to have to go to the top of the program to insert the Declaration.

#2b when a large main program gets too big, it is easier to break into functions if the variable declarations are near the associated code.


#3  code at the botoom is "more readable" especially when printing the program.

#4  code at the bottom uses more paper. If I print a large program with code at the top, I can usually cancel the printout after 4 or 5 pages have come out.




My idea of putting the code last, is theoreticaly safer. But, in reality, those minor disadvantages are adding up, so I may very well join the crowd of folks that put the main code first.


On a separate points,
Yes, good variable names reduces fat finger errors and so does proper scoping.  But a compiler can't enforce the quality of your names whereas scoping can.

Finally, I would never declare a Local variable as Global just because Autoit treats it that way.  My father always taught me, "Two wrongs do not make a right".
 

Thanks for the discussion and I am now closing this problem

[Melba23]

Coded4Decades

 

I would never declare a Local variable as Global just because Autoit treats it that way

So you prefer your variable scopes to be knowingly mis-labelled?

 

Two wrongs do not make a right

But in AutoIt it is not "wrong" to have no Local variables outside functions - that is just the way it is.

But I am not interested in discussing the matter any more - positions on both sides are far too entrenched.

M23

[jchd]

... and, given the massive volume of rains continuously pouring on both UK and continental Europe, we can even say positions are severely bogged down