Good coding practices in AutoIt

[DicatoroftheUSA]

Maybe the error checking could check when a constant is declared twice it could check if it is the same than the first declaration.If so it would be ignored rather than complaining. It would make running legacy scripts easier I think.

[czardas]

... when a constant is declared twice it could check if it is the same than the first declaration.If so it would be ignored rather than complaining.

I think that would lead to laziness.

Edited February 19, 2013 by czardas

[DicatoroftheUSA]

I think that would lead to laziness.

While I don't disagree, that argument could be said for every function of the error checker.

[guinness]

I don't see how this relates to the "coding practice" thread?

[czardas]

While I don't disagree, that argument could be said for every function of the error checker.

I can only presume that constants can not be redeclared in other languages either - perhaps I'm wrong. I think it's fine the way it works right now, although I understand your idea. It's hard to see where this would really be of any great benefit. Is it really needed, and why is it currently the way it is?

@guinness - perhaps it's a dev chat question.

[guinness]

@guinness - perhaps it's a dev chat question.

I agree, this seems more like a request albeit impossible but still a request none the less.

[guinness]

So my idea was this, if possible (not always) wrap/replace Global variables with functions and use the Static keyword instead.

Without the use of a Global variable:

#include <Constants.au3>

Example()

Func Example()
    OpenFilePath(@ScriptFullPath)
    MsgBox($MB_SYSTEMMODAL, '', GetOpenFileName())
EndFunc

Func OpenFilePath($sFilePath = Default) ; Similar to usin a Global variable called $g_sOpenFilePath
    Local Static $sAPIFilePath = ''
    If Not IsKeyword($sFilePath) Then ; Or IsKeyWord(...) = 0
        $sAPIFilePath = $sFilePath
    EndIf
    Return $sAPIFilePath
EndFunc   ;==>SomeFunc

Func GetOpenFileName()
    Return StringTrimLeft(OpenFilePath(), StringInStr(OpenFilePath(), '\', Default, -1))
EndFunc   ;==>SomeFunc

Same example but with a Global variable:

#include <Constants.au3>

Global $g_sOpenFilePath = ''

Example()

Func Example()
    $g_sOpenFilePath = @ScriptFullPath
    MsgBox($MB_SYSTEMMODAL, '', GetOpenFileName())
EndFunc

Func GetOpenFileName()
    Return StringTrimLeft($g_sOpenFilePath, StringInStr($g_sOpenFilePath, '\', Default, -1))
EndFunc   ;==>SomeFunc

If you want a better example (I tried to keep it simple for now) then provide an example using Global variables and I will convert it.

Edited September 4, 2015 by guinness

[guinness]

Before people start to get on my case about the example above, the thread is about 'good coding practice' not what guinness does. Sometimes the best practice isn't always the smartest choice. Though the example above eliminates a "Global" variable, in reality it would be more efficient to use one, I would say.

Edited February 19, 2013 by guinness

[czardas]

Interresting idea guinness. I was just thinking, wouldn't it be necessary to use IsDeclared to make sure you don't overwrite the variable on subsequent function calls?. I'm just thinking out loud. I haven't ever used the Static keyword before: I just read the desciption.

Edited February 19, 2013 by czardas

[guinness]

No, not really. I've only had one use for IsDeclared (look in SciTE Jump's source code to see its usage) and that was because of a significant speed increase.

[czardas]

I just tested it, and I figure the IsDeclared step must be done internally. It's a bit odd that it can't be redeclared. I learned something new.

Edited February 19, 2013 by czardas

[guinness]

I believe it checks the variable name against the variable stack to determine if it's been declared before. Why would you want to re-declare it? To ReDim a variable you just use Static instead.

[czardas]

It appears to fail to be redeclared on subsequent function calls, so it must already exist and the declaration ignored. It's very different from a Global though, as illustrated here

For $i = 1 To 10
    Increment1()
    Increment2()
Next

Func Increment1()
    Local Static $iStatic = 0
    $iStatic += 1
    ConsoleWrite($iStatic & @LF)
EndFunc

Func Increment2()
    Local Static $iStatic = 100
    $iStatic += 1
    ConsoleWrite($iStatic & @LF)
EndFunc

[guinness]

I'm not quite following, that's how Static is meant to work. In what way is it different from a Global? Static is like Global, but only the function that it is declared in can see it.

[czardas]

It's unlike a global in that it can coexist in different functions, each instance having a different current value, as illustrated. So unlike a global, it can't be modified by other instances elsewhere in the script - which is what you were saying Apart from that it's quite similar.

Edited February 19, 2013 by czardas

[guinness]

True, but I presume those who would use the idea would know what they're doing.

[FaridAgl]

Static variables have local scope but their life-time is same as global variables.

Also the line, in the code, which declares them will be executed only once.

Edit: Using Local Static $var or Global Static $var doesn't make any sense (read above).

Edited February 20, 2013 by D4RKON3

[guinness]

Also, functions should not modify global data.

Guilty, I'm afraid. Edited February 21, 2013 by guinness

[BrewManNH]

What's the point of a Global variable if you're not allowed to change it? Might as well just use Const for all globals at that point.

[czardas]

I think several of the potential issues caused by the use of global variables, listed by jaberwocky6669 in are relevant to AutoIt. I also think this needs further elaboration. This is how I see it but please correct me if you know I'm wrong, or if you have information to add then please do so. These are only my thoughts on the subject - no tests have been carried out.

Potential issues affecting AutoIt:

Inadvertent changes to global data. - Higher risk (with bad coding)

Re-entrant code problems with global data. - May affect multiple instances of the same running script.

Code reuse hindered by global data. - TRUE

Modularity and intellectual manageability damaged by global data. - TRUE

Issues I don't know about:

Bizarre and exciting aliasing problems with global data. - Why is this a potential issue?

Edited February 21, 2013 by czardas