Good coding practices in AutoIt

[water]

That was a question, not a statement.

[guinness]

I know. "Why do you say that" is just a phrase/expression that means where did that question come from? I am just surprised that's all.

But if it makes you feel better then perhaps I should have said why do you ask that?

Edited July 18, 2014 by guinness

[Ascend4nt]

18 months ago I started this "best coding practices" thread and I'm happy to say that I can finally see the community taking pride in the code they produce and not using AutoIt as just some "scripting language" it once was.

Wow, really?  Y'know, I get a little irritated by the fact some people let "MVP" or moderator status go to their heads and then somehow lose touch with reality. The fact is, the world isn't THAT affected or concerned with you or your ego. (the same as the rest of us)

[guinness]

Wow, really?  Y'know, I get a little irritated by the fact some people let "MVP" or moderator status go to their heads and then somehow lose touch with reality. The fact is, the world isn't THAT affected or concerned with you or your ego. (the same as the rest of us)

I am not following. I am just a user of AutoIt and nothing more.

[Guest]

I found a way to use high Sleep value while a loop running and without slowing down the loop.

AdlibRegister("Loop",10)

ConsoleWrite(1 & @CRLF)
Sleep(1000)
ConsoleWrite(2 & @CRLF)
Sleep(1000)
ConsoleWrite(3 & @CRLF)
Sleep(1000)
ConsoleWrite(4 & @CRLF)


While 1
    Sleep(1000)
WEnd

Func Loop()
    ToolTip("test")
EndFunc   ;==>Example

; ^^ Instead of using:
;While 1
;   ToolTip("test")
;   Sleep(10)
;WEnd

It works because in this case the loop is not a regular loop.

Instead of writing

While 1
    ToolTip("test")
    Sleep(10)
WEnd

I write:

AdlibRegister("Loop",10)
Func Loop()
    ToolTip("test")
EndFunc

It does not look the same, but if the behavior is the same. In both cases we have a loop.
The difference is that this method have very big and important advantage .

Are there any disadvantages In this method?

Edited September 7, 2014 by Guest

[guinness]

It's not really a best coding practice. Plus I don't see the the real difference, Stuart it wrong with having sleep inside a loop?

[Mat]

I'm glad this got bumped, because I have a possible amendment to make to current coding practices source (such as the wiki), after a discussion with Melba on this.

The current best coding practices wiki page recommends using $id as the prefix for control ids. However, it was pointed out to Melba that on occasion this can conflict with the MsgBox return code conflicts, for seemingly innocuous names such as $idCancel.

I guess that $c is then the best candidate. I know it has another meaning in C, but still I think its the best option.

The the other option (what I currently use) is to use control specific prefixes, such as $btn, $lbl, $inp etc. so that the prefix gives a bit more information about the data the variable is storing. 

[Melba23]

Hi,

I would support a change to $c - and not only because it is what I have been using for some time. As long as there is a clear distinction between handles and ControlIDs I am actually not too fussed what we adopt, but using a prefix which can so very easily cause conflicts with commonly included constants (even if they are not actually used in the script) is definitely not ideal.

M23

[JohnOne]

I'd have went with $ctl

[guinness]

Changing to c in the wiki will conflict with the standards set in the help file. Maybe the discussion could be moved to the private Forum, as it's beyond the scope of this thread.

[JohnOne]

This is a coding best practices thread, how could it possibly be out of the scope of the thread. Putting it where the great unwashed of no consequence  cannot see it, is of course though, your prerogative. 

[guinness]

Because it's also related to the help file and UDFs, which should be discussed between those working on AutoIt.

[czardas]

Because it's also related to the help file and UDFs, which should be discussed between those working on AutoIt.

 

guinness, you're confusing me. A few posts ago said you are just a user of AutoIt and nothing more.

$c gets my vote too - although $id should be acceptable in both situations since it appears a to be a conjunction of integer and binary, which fits the description and is suitable in a variety of other situations. Perhaps swap the letters $diBinaryInteger - problem solved!

Edited September 9, 2014 by czardas

[JohnOne]

Did not know there was a best coding practices in help file, I'll take a closer look.

But regardless, comments or discussions about a variable prefix is not super secret and by every account has a place in this thread.

[orbs]

i've been using $g as a prefix for control ID's , as g stands for graphic. as the letters "g" & "h" are closely related in order, this is also very convenient in relation to using $h for the handle of the control. for example:

Local $gButtonOK = GUICtrlCreateButton("OK", 100, 100, 60, 20)
Local $hButtonOK = GUICtrlGetHandle($gButtonOK)

so i have a very clear distinction between the control ID and the handle of the control, both carrying the same name but with different prefix.

Edited September 9, 2014 by orbs

[czardas]

Well Valik suggested $g should be used for global variables to avoid conflicts with constants native to AutoIt. That was a while ago though. Since AutoIt is developing with so many new features it's difficult to give a final answer on questions like this. It's a bit like fashion, things keeps changing - although some things remain constant. I think $i, $a and $v are unlikely to change for a while, and probably a few more can be included in the category of being stable.

I think someone said constants should be upper case earlier, but I would never restrict myself in such a way personally. Although unofficial, $k is a good choice for constants (typical historically in physics and also in programming). Code should be readable if you wish to share or update it - and sometimes unreadable, but only for the right reasons.

Edited September 9, 2014 by czardas

[guinness]

Valik meant $g_, but if the variable is local then that prefix is invalid.

Since AutoIt is developing with so many new features it's difficult to give a final answer on questions like this. It's a bit like fashion, things keeps changing - 

I give answers and you guys tell me I am wrong. So what else can I do? For example...

Local $vVar = "" ; This is local to the scope.
Global $g_vVar = "" ; This is Global as it's used inside function(s).

Func Example()
    $g_vVar = Null
EndFunc

Even Jon confirmed this as being correct.

Edited September 4, 2015 by guinness

[czardas]

Excuse me guinness, I never said you were wrong, merely that you making seemingly contradictory statements.

Here =>

and here =>

Now let me see what you just said here.

Global $g_vVar = "" ; This is Global as it's used inside function(s).

;This is what I call wrong: the variable is global regardless of where you use it.

Anyway, I'm not so bothered where you want to discuss this. Beyond avoiding conflicts, I consider variable prefixes somewhat arbitrary.

Edited September 10, 2014 by czardas

[guinness]

Excuse me guinness, I never said you were wrong, merely that you making seemingly contradictory statements.

Here =>

and here =>

Actually there is a mistake, it should now read I was a user of AutoIt.

As for contradicting myself I can't see how those two comments are related. There are a group of people behind the scenes working on AutoIt and if Mat decides to change the wiki documentation for UDF creation (which represents the official documentation) then it's best to discuss such matters there. There as a lot of examples which will need to be ammended to reflect this documentation change. I guess Mat understood my point, which is what counts.

[czardas]

No worries guinness. Just what you say confuses me sometimes. I have read Mat's wiki article many times and found it very helpful. I think readability and standard practices should take precedence in most situations, but not necessarily always. The fact that I'm able to voice such an opinion on a public forum makes me happy.