Good coding practices in AutoIt

[AZJIO]

$WS_OVERLAPPEDWINDOW + $WS_CLIPCHILDREN

BitOR($WS_OVERLAPPEDWINDOW, $WS_CLIPCHILDREN)

[guinness]

Care to explain?

[AZJIO]

10 + 2 = 12

BitOR(10, 2) = 10

10 + 2 <> BitOR(10, 2)

10 = 8+2

12 = 8+4

10 + 2 = 8+4 (the two are not found)

00000001 = 1

00000010 = 2

00000100 = 4

00001000 = 8

00010000 = 16

00100000 = 32

00001010 = 8 + 2

00001100 = 8 + 4

The BitOR function excludes possibility of addition of a constant in style which already contains this constant.

Edited February 3, 2013 by AZJIO

[Jos]

$WS_OVERLAPPEDWINDOW + $WS_CLIPCHILDREN

BitOR($WS_OVERLAPPEDWINDOW, $WS_CLIPCHILDREN)

I fully understand the logic with BitOR() and the potential issues when the constants aren't correct, but assuming we did a proper job creating these constants, there should be no need to be anal about it:

#include <WindowsConstants.au3>
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $WS_CLIPCHILDREN = ' & $WS_CLIPCHILDREN & @crlf) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $WS_OVERLAPPEDWINDOW = ' & $WS_OVERLAPPEDWINDOW & @crlf) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : BitOR($WS_OVERLAPPEDWINDOW, $WS_CLIPCHILDREN) = ' & BitOR($WS_OVERLAPPEDWINDOW, $WS_CLIPCHILDREN) & @crlf) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $WS_OVERLAPPEDWINDOW +$WS_CLIPCHILDREN = ' & $WS_OVERLAPPEDWINDOW + $WS_CLIPCHILDREN & @crlf) ;### Debug Console

Jos

Edited February 3, 2013 by Jos

[BrewManNH]

What is the consensus on functions doing one thing and only one thing? In other words, would it be considered good coding practice to make your functions work this way?

I'm throwing this out there because I honestly don't know what the best practice is for this case.

I read on here about functions doing one thing and only one thing to make the code easier to follow.

Effectively using functions

One of the biggest challenges new programmers encounter (besides learning the language) is learning when and how to use functions effectively. Functions offer a great way to break your program up into manageable and reusable parts, which can then be easily connected together to perform a larger and more complex task. By breaking your program into smaller parts, the overall complexity of the program is reduced, which makes the program both easier to write and to modify.

Typically, when learning C++, you will write a lot of programs that involve 3 subtasks:

• Reading inputs from the user
• Calculating a value from the inputs
• Printing the calculated value

For simple programs, reading inputs from the user can generally be done in main(). However, step #2 is a great candidate for a function. This function should take the user inputs as a parameter, and return the calculated value. The calculated value can then be printed (either directly in main(), or by another function if the calculated value is complex or has special printing requirements).

A good rule of thumb is that each function should perform one (and only one) task. New programmers often write functions that combine steps 2 and 3 together. However, because calculating a value and printing it are two different tasks, this violates the one and only one task guideline. Ideally, a function that calculates a value should return the value to the caller and let the caller decide what to do with the calculated value.

Now of course, this applies to C++ programming, but I wonder if it should apply equally to good coding practices in AutoIt?

I found that by doing this in one of my larger scripts, it makes the script easier to follow without so many comments needed. Now the functions are named what each piece was doing, rather than a loop in the middle of a function with a comment telling me why it's there.

[guinness]

I would say it applies to AutoIt. A pity AutoIt doesn't have class instances,

[FaridAgl]

Constants, at least in Windows APIs are designed somehow that there won't be any difference in using BitOr() ro simply + add together.

As I know they are a multiple of 2 of each other, first one is 1, then 2, 4, 8, 16, 32 etc. So there won't be any trouble using +.

For example MsgBox in from the help says:

16 Stop-sign icon
32 Question-mark icon
48 Exclamation-point icon
64 Information-sign icon consisting of an 'i' in a circle
256 Second button is default button
512 Third button is default button
4096 System modal (dialog has an icon)
8192 Task modal
262144 MsgBox has top-most attribute set
524288 title and text are right-justified

Or its father!!!:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms645505(v=vs.85).aspx

Any correction is welcomed.

Edit: Well, taking a deeper look gives me some lights! Am I wrong?!

Edited February 6, 2013 by D4RKON3

[guinness]

Hi D4RKON3,

trancexx suggested this wasn't the case, see

[FaridAgl]

HI!

OK, but I'm pointing to BitOr() not the MsgBox, I can't understand why should I read your given link :S

[guinness]

But you used the MsgBox as an example and as trancexx suggested using BitOR is a more appropriate method than adding the constants together for MsgBox.

[BrewManNH]

The point guinness is trying to make in linking that post from trancexx is that some values are linked to more than one constant name, so if for instance you used the constants $MB_IConstop and $MB_IConerror together but didn't use BitOr, you'd get an entirely different result than you expect.

[FaridAgl]

@BrewManNH.

Thanks, now it makes sense.

@guinness,

Thank you too, for making this happen.

[guinness]

The point guinness is trying to make in linking that post from trancexx is that some values are linked to more than one constant name, so if for instance you used the constants $MB_IC&#111;nstop and $MB_IC&#111;nerror together but didn't use BitOr, you'd get an entirely different result than you expect.

I don't get why the Forum messes up those variable names. Hope this will be fixed in the new version.

[BrewManNH]

I copied them (the variable names) from the MSDN site, so maybe there's something funky with their encoding.

[Mat]

Constants, at least in Windows APIs are designed somehow that there won't be any difference in using BitOr() ro simply + add together.

As I know they are a multiple of 2 of each other, first one is 1, then 2, 4, 8, 16, 32 etc. So there won't be any trouble using +.

The whole idea of constants is that you shouldn't have to know the value at all, just the name.

And having multple constants declaring the same value is not the only problem, there are a lot of flags which are pre-set combinations too:

$WS_POPUPWINDOW+$WS_CAPTION+$WS_BORDER

BrewmanNH, if you read through the conversation I had with TranceXX you'll see all our constants had exactly the same thing. I would imagine onerror and onstop are somehow special names for the forum.

[PlayHD]

Another tip would be to use a 'if' with 'and' the test of variables and functions, put the variables first and then put your functions, in case the variables not meet the conditions then function will not be executed, saving time.

$val = False
If $val = True And _IfFunc() Then
ConsoleWrite("TRUE")
Else
ConsoleWrite("FALSE")
EndIf


Func _IfFunc()
Sleep(1500)
Return ConsoleWrite("IF"&@LF) ;not show the message because $val is false, and _IfFunc() not need to execute anymore, because we use 'AND'
EndFunc

ps. sorry for my english

a moderator if he wants to correct my spelling mistakes.

Edited February 14, 2013 by PlayHD

[BrewManNH]

I was thinking about the whole "avoid using Global variables" recently and decided to check something.

I have a fairly large script (large for me) that I've been writing/playing around with that includes a few UDFs from here and some standard UDFs as well. Right now my script currently has 30 or so variables declared as Global, not including variables assigned to GUI controls, which I should probably put into an array at some point. What is the general prohibition against using Global variables? When you're sure there won't be any changes to them that you're not 100% aware of, so you are sure that the values they hold will be the expected values? Is it just some type of argumentum ad populum or is there something more concrete than just a lot of people saying "don't do this"? Because if it's the former, then can anyone explain where this mindset comes from, and if it's the latter can anyone explain why it's a "bad thing"?

[Chimaera]

What is the consensus on functions doing one thing and only one thing? In other words, would it be considered good coding practice to make your functions work this way?

I'm throwing this out there because I honestly don't know what the best practice is for this case.

I read on here about functions doing one thing and only one thing to make the code easier to follow.

Now of course, this applies to C++ programming, but I wonder if it should apply equally to good coding practices in AutoIt?

I found that by doing this in one of my larger scripts, it makes the script easier to follow without so many comments needed. Now the functions are named what each piece was doing, rather than a loop in the middle of a function with a comment telling me why it's there.

After a few times of working on some bits with guinness it started to make sense to me.

I always try to make a single entity function for all the things i add, it makes it so much simpler to find whats messed up..

Alos i can add functionality simply

If "what i need doing is right" Then
_1st Function()
_2nd Function()
Etc()
Etc()
EndIf

Makes much more sense to me

[Xibalba]

ok, what I said is a little bit wrong.

Here is my example :

Global $var
Local $var
;these vars are declared in the global scope, no matter of their statement, it's Global.
;to avoid any ambiguity, use only the Global statement.

Global $aArray[2] = [1, 2] ;just an array.

Func _myFunc()
Local $var
;only use the local statement inside functions, if you want to declare a Global var,
;it's better to first initialize it in the global scope.

ReDim $aArray[3] ;resize the array and keep its content.

Dim $aArray[2] ;erases the content of the array. [and resizes it]

;it's better to use Dim/ReDim to edit an array, otherwise use Local or Global to declare a var.
EndFunc

Of course I don't say it's right nor I'm the one to follow and I'm opened to criticisms.

@czardas

If you declare a non existing var with the Dim statement, then It will be declared according to the current scope, otherwise it will take the scope of the declared var.

Just to clarify this code example; usage of the $var variable will give different results wether used inside the _MyFunc() function, or somewhere else.

..Which leads us to best practice regarding naming of variables. In my oppinion you should avoid having two variables with the same name, in different scopes. Then name them $g_var and $l_var to avoid mixing them up.

[FireFox]

Which leads us to best practice regarding naming of variables. In my oppinion you should avoid having two variables with the same name, in different scopes. Then name them $g_var and $l_var to avoid mixing them up.

I agree with you and I recently started to name global vars with an underscore like this :

Global $_sMyString = "toto"

Func _myFunc()
    Local $sMyString = "toto"
EndFunc

Edited February 16, 2013 by FireFox