In Defence of Magic Numbers

[czardas]

"settings.ini" is a magic string (for want of a better word for it). $SETTINGS_FILE is a named constant.

The latter is nearly always better.

 

Yes and I would say even better if you can declare it as a local variable, and not necessarily as a constant.

Edited December 15, 2013 by czardas

[BrewManNH]

You would use a constant in this case because you don't ever want it to be changed. So if you inadvertently write your function with a ByRef that references your ini file you'll know that you did something wrong before you ever run your code. Also, if you're going to reference the ini file in several areas of your code, it's easier to set it as a global, and not have to code it that you're passing it all over the script. It doesn't mean it can't be a local, it's just a lot easier to make it a global. 

[czardas]

This is presumptuous. You might want to change it.

[czardas]

I think we may be splitting hairs a little bit. I understand and accept the arguments for using global constants, but I do not accept that it is always preferable. I think it depends entirely on the situation.

[BrewManNH]

Who said anything about "always preferable"? You can always make them local constants if you want.

[iamtheky]

What is chat for if not hair splitting?

I concede that magic numbers are inferior in all cases, but only for the typo argument.  Being able to error the compile for a typo is killer.

However, I am lazy as balls and will no doubt continue to use the most familiar numbers.

[czardas]

I concede that magic numbers are inferior in all cases, but only for the typo argument.

 

I disagree. If you have the impossible task of sending 16 simultaneous messages, the best you can do is send binary direct (in sequential chunks) and this is still a compromise. Some preprocessing can help, but suppose you have over 2000 binary variants to select from, giving them each a name is overkill. You would most likely use an array of 'magic numbers'.*

If predefined constant names make reading the code more difficult, then there is good reason to rename them; and if obfuscation is your goal, then using difficult to understand binary is probably as good as any obscure name. Perhaps development requires you to know if a constant is odd or even - in such a case the last thing you want to do is use a name instead of a number. I'm sure there must be many plausible exceptions - more so in development than with release code.

* $aMagicNumber[2000] could perhaps be considered as a named constant.

However, I am lazy as balls and will no doubt continue to use the most familiar numbers.

 

Well you are not the only one.   Familiarity counts for a lot.

Edit

This post just about sums up most of my thoughts on this subject. If someone like trancexx, jon or valik were show up and say I am missing something fundamental, or that my argument is a straw man, I would certainly not ignore their criticism. I hold each of them in high regard.

Edit 2

I forgot to mention that performance degradation in extreme cases, where memory is allocated to too many variables, is a very real effect.

Edited December 16, 2013 by czardas

[guinness]

Why does it have to be just those three? Stick to your guns if you feel you're right. Jon is the one who designed the language, so has a good idea of what is right and wrong, regardless of what the "standards and practices" tell us about coding.

Just to annoy those who feel Local in "Global scope" is Global. Though it works like that, it shouldn't be regarded as that, case in point....

#include <Constants.au3>

Local $sVar = 'This variable is only used in the scope it''s declared in, therefore imagine if this scope was wrapped in a function called "Main".'
Global $g_sString = 'This variable is used not only in this scope ("Main") but also inside other functions e.g. SomeFunc()'

SomeFunc()

MsgBox($MB_SYSTEMMODAL, '', $sVar) ; Display in a MsgBox().
$sVar = ''

SomeOtherFunc()

Func Example()
    Local $sText = 'This is some text.' ; The variable is Local and is declared and initialised when required.
    ConsoleWrite($sText & @CRLF) ; Display in the console.
    
    $sText = 'Change the variable which is local to the scope it''s declared in.' ; Change the variable's contents.
    ConsoleWrite($sText & @CRLF) ; Display in the console.
EndFunc

Func SomeFunc()
    $g_sString &= @CRLF ; Append CRLF to the string.
    ConsoleWrite($g_sString) ; Display in the console.
EndFunc

Func SomeOtherFunc()
    $g_sString = '' ; Clear the contents of the Global variable.
EndFunc

Edited December 16, 2013 by guinness

[czardas]

Why does it have to be just those three?

 

guinness I said 'someone like' those three, which also includes a number of other people, who's opinion I would not like to question. Likewise I do not dismiss points made by anyone here without contemplation. Most points I have read seem very reasonable.

If some of the things I have said are incorrect, then I will be happy to review them and adjust my less rigid and perhaps undisciplined approach.

Edited December 16, 2013 by czardas

[guinness]

guinness I said 'someone like' those three, which also includes a number of other people, who's opinion I would not like to question. Likewise I do not dismiss points made by anyone without contemplation. Most points I have read seem very reasonable.

Okay.

[Mat]

Just to annoy those who feel Local in "Global scope" is Global. Though it works like that, it shouldn't be regarded as that, case in point....

 

Well... It's actually not a bad way to think about it.

When you use a language with nested functions/closures and the like you'll find that scopes aren't quite as simple as they seem.

[Melba23]

guinness,

 

Local $sVar = 'This variable is only used in the scope it''s declared in, therefore imagine if this scope was wrapped in a function called "Main".'

But it is not in a function and so should be declared as Global as that is the scope it will have in the script. If you put it in a function called "Main" then by all means declare it as Local if that is the scope it requires - but not when it is not.

M23

P.S. Not at all annoyed, by the way.

[guinness]

But it's not used anywhere else and thus is "Local to the scope" not Global. Valik was the one (when I started on the help file) who drilled this into me. For example I started to change examples like the one below to Global, but he made a point about this to me in the MVP section that it's actually Local and not Global.

Local $sString = 'Some string'
$sString = StringToBinary($sString)
ConsoleWrite($sString & @CRLF)

Read this >> 

Edited December 16, 2013 by guinness

[Melba23]

guinness,

I have read Valik's comment and discussed on teh forum it many times - I did not and still do not agree with it. While I see the logic of doing what he suggested when using a language which does have that sort of scoping, this is absolutely not the case in AutoIt and I firmly believe that declaring main script variables as Local when they are in fact treated as Global could well cause huge problems to someone who does not grasp the subtlety of the original argument. AutoIt is designed first and foremost for those who are not experienced coders - in my opinion some of those who are sometimes lose sight of this simple fact.

End of transmission.

M23

[guinness]

in my opinion some of those who are sometimes lose sight of this simple fact.

I am aware of this, but if people really wish to expand their knowledge of coding/AutoIt then we (Dev/MVP/Mods/Users) should be here to help and offer advice of "hey, common coding practices can be applied to AutoIt too." Edited December 16, 2013 by guinness

[czardas]

Can we have magic strings with fairy lights for christmas? Ask jon.

[guinness]

I have to add that I haven't forgotten about the novice user of AutoIt. You will see most examples in the help file were a little hard to decipher, hence major re-writes to all (ex. GUI) functions. I have also tried to accommodate for those who are interested in expanding their knowledge of AutoIt, something I had to inspire in myself to learn as nothing much had been discussed about it on the Forum before.

 

End of transmission.

Okay.

For now I will take a break discussing about the best practices of AutoIt and go back to having just a support Forum. Most of what I have had to teach or discuss about this subject has already been said and it's just regurgitating the same information from my end.

Edited December 16, 2013 by guinness

[Jon]

I've always thought of "Local" to mean "Local to the current scope". It's just that outside of a function that the current scope happens to be the global scope. That's pretty much how scope is differentiated within the internals so it's an OK way to think about it.  Allowing the feature to create a new global variable from within a function was probably a mistake (no matter how sometimes useful - i.e. We should have just left it as Dim with no Local and Global).

[ripdad]

... We should have just left it as Dim with no Local and Global.

Oh no, That would make too much sense. What would people dis-cuss around here?

[czardas]

Vaguely related:

The other day; I imagined a pseudo type syntax, similar to the following, which could be used to force a Local copy of a global variable passed as a parameter. It offers no additional, or practical, advantage other than being easy to follow (IMO).

;

Pseudo Code

Global Const $gvVar = True

_Anything($gvVar)

Func _Anything(Not ByRef $gvVar)
    $gvVar = False
EndFunc

;

Although I think 'Not ByRef' is perhaps a bad combination / expression for different reasons. It was merely a passing thought.

---

Something I think would be very useful would be to have optional ByRef parameters (for passing around large amounts of data - or not), but perhaps there's enough going on right now. Maybe sometime in the future.

Edited December 19, 2013 by czardas