if global variables should be avoided, what's the best alternative? (in the included example)

[Imbuter2000]

I've a general question about the best practice in programming with function in AutoIT or in general:

supposing to have multiple unrelated variables that you set only inside a function and read outside (after) that function, how would you do?

would you declare them as global at the very beginning of the script? or return the variables from the function as an array (losing the useful variable names)? what's the best/most used practice?

I read that global variables should be avoided... but I can't find a better alternative...

Example of how I'ld do such a script, with global variables:

Global $current_song_names, $last_query_PCname, $last_query_time

some code aaaaaa...
query()
some code bbbbbb...
query()
some code cccccc...
query()
some code dddddd...

Msgbox("","", $current_song_names & @CRLF & $last_query_PC_name & @CRLF & $last_query_time)


Func query()
     some code ppppp...
     $current_song_names &= FileRead("c:\current_song_name.txt") & @CRLF
     $last_query_PCname = @ComputerName
     $last_query_time = @HOUR & ":" & @MIN & ":" & @SEC
     some code qqqqq...
EndFunc

How would you do it instead?

Edited December 31, 2012 by Imbuter2000

[Quual]

here is one method

Func MsgboxQueryResults()
    Local $current_song_names, $last_query_PCname, $last_query_time
    some code aaaaaa...
    query($current_song_names, $last_query_PCname, $last_query_time)
    some code bbbbbb...
    query($current_song_names, $last_query_PCname, $last_query_time)
    some code cccccc...
    query($current_song_names, $last_query_PCname, $last_query_time)
    some code dddddd...

    Msgbox("","", $current_song_names & @CRLF & $last_query_PC_name & @CRLF & $last_query_time)
EndFunc

Func query(ByRef $current_song_names, ByRef $last_query_PCname, ByRef $last_query_time)
     some code ppppp...
     $current_song_names &= FileRead("c:\current_song_name.txt") & @CRLF
     $last_query_PCname = @ComputerName
     $last_query_time = @HOUR & ":" & @MIN & ":" & @SEC
     some code qqqqq...
EndFunc

Edited December 31, 2012 by Quual

[Imbuter2000]

Right, byref provides an alternative...

but is it a better practice? should I always prefer it? even when the list of variables is long and/or some of them are setted and used only when specific limited conditions are met?

[Melba23]

Imbuter2000,

I really would not worry about it too much. The nature of AutoIt makes it difficult to avoid Global variables - so if you feel the need to use them then do so. Personally I would rather have legible code with some sensible Global variables than a psuedo-elegant web of parameters passed between functions - remember you are going to have to maintain this code in the future.

Just try and avoid making every variable in the script Global in scope - that is not the way to go.

M23

[Imbuter2000]

Thanks Melba23, that sounds very reasonable!

[kylomas]

Imbuter2000,

This subject comes up every so often. If you search the forum you will find some excellet discussion/explanation of technical requiremets and coding styles.

kylomas

[DicatoroftheUSA]

For me the problem I have with globals is when reviewing a script. I ask myself, where did that come from and what should be it be set to? With a long enough script, that can become difficult to answer. If the value is specific, or passed to the function there is no question. Of course to helps to prefix global variables, eg $gsStuff.

About the only variable I prefer to be global when it could be local is magic numbers constants. Because they can help with clarity.

for example

global const $gciStopSign=16
global const $gciYesandNo=4

MsgBox($gciStopSign+$gciYesandNo,"hugh","hello")

Edited December 31, 2012 by DicatoroftheUSA

[czardas]

Another common use for Global variables is for flags which are set to trigger events on receiving windows messages. For example to interrupt a running script when clicking on a button. There must be many instances where using globals will be at least the easiest, if not sometimes the only possible solution. I'm absolutely in agreement with all the comments above.

Edited January 1, 2013 by czardas

[guinness]

About the only variable I prefer to be global when it could be local is magic numbers constants. Because they can help with clarity.

I would prefer some sort of pre-processor, but you're correct this is a good approach.

[jaberwacky]

There isn't a big problem with passing arguments to your functions. This means that you don't have to go scouring your code to find the definition of some global variable which is most likely able to change at any given moment under all sorts of conditions. This is especially pertinent for large code bases. Exceptions to this are native global constants and user defined global constants. If your argument list becomes too long then it's time to look into breaking your function into smaller functions. This helps with comprehension of the code by reducing complexity.

Edited January 1, 2013 by jaberwocky6669

[jchd]

Another reason to prefer parameters to globals is that functions can be reused much more easily in other projects. That helps modularity to a great extend: you don't have to practice surgery to export functions and that favors grouping famillies in reuseable includes.

But of course it isn't a strict rule to apply blindly and go away happy in all cases. For instance, writing a function taking 83 arguments is obviously a bad design in the first place.

[czardas]

Good points jchd. Perhaps there are one or two exceptions where large numbers of parameters are possibly acceptable. Some bitwise functions can take up to 255 parameters. I never saw anyone try it though.

[kylomas]

You'll notice that a common theme is coding style. Establishing a variable naming convention is important, especially in a large project.

As far as scope is concerned, consider the following code based on your OP

; scope is local to script making variables in scope to any called fuction

local $current_song_names = '123', $last_query_PCname = 'abc', $last_query_time = '2013, Happy New Year!'

query()
_two()

Func query()
     ConsoleWrite($current_song_names & @lf & $last_query_PCname & @lf & $last_query_time & @lf)

    local $current_song_names = 'hmmm...something changed'  ; scope is local to function query() making the value visible only within this function

    ; from the script perspective there are two variable named $current_song_names at this point, one visible at the script level and one local to this function

    ConsoleWrite('variable after chaged within function = ' & $current_song_names & @LF)
EndFunc

func _two()
    ConsoleWrite($current_song_names & @LF)  ; using the variable with script scope, the var with function scope was destroyed when the func ended
EndFunc

kylomas

[AZJIO]

No need to fear the global variables. If a person does not understand, he rushes from one extreme to another.

Global variables is not a crime. It is important that your script gave the declared results.

When you have a complex script, you will understand how to organize. You won't be able to perceive disordered information.