Good coding practices in AutoIt

[Guest]

My advice is not about Coding
it is about how to organize your code ..

I think that this is an unfamiliar concept  especially because I made it better.

My idea is to always use #Region & #EndRegion + using the TAB when needed.

* ^ I added the green lines in an image editor. It was good if it was like that naturally.

 

In addition, after you made this order, when you open the script go to "View->toggle all fold" and then
always use the +/- button... When you want to read function/region, click on "+" and when you done, always click on "-"

The #Region & #EndRegion and the +/- is  one of your best friend when it comes to reading the code.

 

* Edited - I added more image

Edited February 5, 2016 by Guest

[lorenkinzel]

Makes good sense, I like it.

When I get all the tabs/regions closed & save & exit, upon re-opening all tabs are open again.

What am I missing (other than coding skills)?

[Guest]

6 minutes ago, lorenkinzel said:

Makes good sense, I like it.

When I get all the tabs/regions closed & save & exit, upon re-opening all tabs are open again.

What am I missing (other than coding skills)?

I also have this..

I do not know about a way to set that the option "View->Toggle all folds" will run automatically when you open the script.

I'd be happy if someone will solve it

Edited February 5, 2016 by Guest

[lorenkinzel]

Well, at least you have shown me how to close them all at once.

Good enough for today. Thanks

[Guest]

I'm glad you liked it.
In my experience - since I work in this way, My coding becomes much much easier and simpler

Edited February 5, 2016 by Guest

[JohnOne]

4 minutes ago, gil900 said:

I'm glad you liked it.
In my experience - since I work in this way, My coding becomes much much more easier and simpler

 

[TheSaint]

5 hours ago, gil900 said:

My idea is to always use #Region & #EndRegion + using the TAB when needed.

I can honestly say that I have never thought to use it as you have, in fact I'm not sure I have ever used the Region commands at all. Now you have given me a reason to consider using then. So Thanks!

My code is generally highly organized, so I can see where adding this to the mix, could be very effective.

Something I do, that others may not, is create Jump sections at the start of my script, for functions, which are also organized alphabetically throughout the script too.

i.e.

Quote

; AlphaFunction(), BetaFunction(), GammaFunction()

To get to that function quickly, I double-click it then use Jump.

On my setup, I have a button on my SciTE toolbar (Toolbar For Any) which performs the Jump command.

In fact, I have modified that button, to run some code and present me three choices.

YES [1] Jump to function.
NO [2] Jump to menu control.
CANCEL [3] Jump to text (which incorporates a Next ability).

So as well as Function jumps, I also sometimes setup (in big scripts) Section jumps (unique text). Also, because I generally declare all my controls as Globals at the start of the script, I can use those declarations for jumps to the menu entry (i.e. Case $msg = $Button_1).

So the start of a script could look like the following. I call them quick jumps.

Quote

; FUNCTIONS
; AlphaFunction(), BetaFunction(), GammaFunction()

; SECTIONS
; GUI_CONTROLS, SOUND_TAB, SOUND_TAB_SETTINGS, VIDEO_TAB, VIDEO_TAB_SETTINGS

Global $Button_1, $Button_2
Global $Combo_one, $Combo_two

They certainly help speed things up, allowing me to (at times) search a small section of text, to get to a function etc I have forgotten the name of. Obviously it is important to name your functions etc appropriately.

Edited February 5, 2016 by TheSaint

[guinness]

SciTE Jump does that already and it's part of SciTE4AutoIt.

You should also be prefixing your globals to distinguish what is a local and not. This is all explained in the style guide and the reason I created this thread.

It also appears I wasn't crazy so many years ago. Just search Airbnb JavaScript and you will see many people, including me, are adopting their guide as a way to write ES2015.

Oh and select is awful for gui messages. Use switch. You type alot less, plus select is syntagic sugar for if else if.

Edited February 5, 2016 by guinness

[TheSaint]

3 hours ago, guinness said:

SciTE Jump does that already and it's part of SciTE4AutoIt.

I knew that, and indeed in the first version of my Toolbar For Any program, the Jump button just used F11 or whatever it was that SciTE used. I later added the other two options, accessed by the same button, and which now presents a YES, NO, CANCEL dialog to do one of those three things I mentioned above.

I will take into consideration the other issues you have raised.

I wasn't aware you prefixed Globals with anything other than data type, and I thought Local was Local and not Global, so obviously I must have missed something in the preceding pages in this topic. As most of the variables I use, are either a string or a number I haven't bothered with prefixes ... especially as they add an alien look  ... to me anyway ... and because I keep things as simple as possible on the off chance a newbie might be studying my code. So I leave all the fancy stuff to you experts, unless I find a pressing reason to do otherwise ... as it lets me concentrate on the hard stuff ... and look more like a hobby programmer of the back yard kind ... which appeals to my ego.

P.S. I blame JohnOne for luring me back to this topic ... I was stalking him.

Then gil900 grabbed my attention and interest, before I could flee ... can't help good luck.

[Guest]

5 hours ago, TheSaint said:

I can honestly say that I have never thought to use it as you have, in fact I'm not sure I have ever used the Region commands at all. Now you have given me a reason to consider using then. So Thanks!

I imagined that it was the same with everyone. which is exactly why I posted it

I edited my first post about this ( #381 ) and uploaded new important image about how I suggest writing it inside.
Look at the post again.

JohnOne, Thanks you for correcting me. Next time, please do it in private.

 

 

[guinness]

@TheSaint, it's all here >> https://www.autoitscript.com/wiki/Best_coding_practices

[TurionAltec]

Is there any thought of including these best practices (basically the contents of the wiki) in the help file? After almost 9 years of using AutoIT, I finally set out to figure out why people have random letters in front of their variable names. I'm also bad at using magic numbers. These are things I'm going to change in my own coding.

 

[mLipok]

HelpFile is constantly improved.
 

You can read about here:

also here:
HelpFile tickets.

 

If you find any bad coding ... first try to ask in discussion topic, to start improvement process.
Of course you should show examples what you mean.

The HelpFile from the last Beta have quite a lot of changes, but any new constructive comments/changes, from any forum member will be helpful.

Regards,

mLipok

[guinness]

Best coding practices guidelines are fine where they are, since the help file is only about the release. At least with the wiki, the practices can organically change without having to issue a release, all because of a guideline change.

[mLipok]

MSDN: Anticipating Errors

Quote

Any program that accepts data from a user must include code to validate that data before sending it to the data store. You cannot rely on the data store, the provider, ADO, or even your programming language to notify you of problems. You must check every byte entered by your users, making sure that data is the correct type for its field and that required fields are not empty.

This quote applies to ADO, but whether this quote should not refer to any function ?

[JLogan3o13]

In a general way I would agree that you need to validate incoming data. As many scripts we see on the forum are just taking in a string to a temp variable, not sure that the "You must check every byte entered by your users" is valid for every situation. For more complex applications, of course.

[mLipok]

1 minute ago, JLogan3o13 said:

not sure that the "You must check every byte entered by your users" is valid for every situation.  For more complex applications, of course.

But for UDF ?
I mean not only standard UDF but also for example for any UDF , also this which me or you, created for our own purposes.

btw.
From some time I'm working in this way. You can observe it, in almost all my recently released UDF.

 

[BrewManNH]

I would think that the script should be doing the checking for valid input, not the UDFs. Otherwise you'd make the UDFs overly complex and probably slower. The UDFs should check that the data type is correct, i.e. an array is expected, is it an array, but the UDFs shouldn't be validating that the data in the array is valid for what you want to do.

[JLogan3o13]

Agreed. I thought you were asking about coding practices in general @mLipok, you didn't specify in a UDF.

[mLipok]

@JLogan3o13

This was general question, but you narrowed my question, and I clarified, in this way we created the conversation, and we are trying determine the best approach. 

@BrewManNH

I agree that we can not check content (with some exceptions like testing empty string), but only type and size.

Example:

expandcollapse popup

Func __ADO_Command_IsValid(ByRef $oCommand)
    Local $iValidationResult = __ADO_IsValidObjectType($oCommand, 'ADODB.Command')
    Return SetError(@error, @extended, $iValidationResult)
EndFunc   ;==>__ADO_Command_IsValid

Func __ADO_IsValidObjectType(ByRef $oObjectToCheck, $sRequiredProgID)
    If Not IsString($sRequiredProgID) Then
        Return SetError($ADO_ERR_INVALIDPARAMETERTYPE, $ADO_EXT_INTERNALFUNCTION, $ADO_RET_FAILURE)
    ElseIf $sRequiredProgID = '' Then
        Return SetError($ADO_ERR_INVALIDPARAMETERVALUE, $ADO_EXT_INTERNALFUNCTION, $ADO_RET_FAILURE)
    ElseIf Not IsObj($oObjectToCheck) Then
        Return SetError($ADO_ERR_ISNOTOBJECT, $ADO_EXT_INTERNALFUNCTION, $ADO_RET_FAILURE)
    ElseIf StringInStr(ObjName($oObjectToCheck, $OBJ_PROGID), $sRequiredProgID) = 0 Then
        Return SetError($ADO_ERR_INVALIDOBJECTTYPE, $ADO_EXT_INTERNALFUNCTION, $ADO_RET_FAILURE)
    EndIf

    Return SetError($ADO_ERR_SUCCESS, $ADO_EXT_DEFAULT, $ADO_RET_SUCCESS)
EndFunc   ;==>__ADO_IsValidObjectType

Func _ADO_Command_CreateParameter(ByRef $oCommand, $sName, $iSize, $vValue, $iType = $ADO_adChar, $iDirection = $ADO_adParamInputOutput)
    ; Error handler, automatic cleanup at end of function
    Local $oADO_COM_ErrorHandler = ObjEvent("AutoIt.Error", __ADO_ComErrorHandler_InternalFunction)
    If @error Then Return SetError($ADO_ERR_COMHANDLER, @error, $ADO_RET_FAILURE)
    #forceref $oADO_COM_ErrorHandler

    __ADO_Command_IsValid($oCommand)
    If @error Then
        Return SetError(@error, @extended, $ADO_RET_FAILURE)
    ElseIf Not IsString($sName) Then
        Return SetError($ADO_ERR_INVALIDPARAMETERTYPE, $ADO_EXT_PARAM2, $ADO_RET_FAILURE)
    ElseIf $sName = '' Then
        Return SetError($ADO_ERR_INVALIDPARAMETERVALUE, $ADO_EXT_PARAM2, $ADO_RET_FAILURE)
    ElseIf Not IsInt($iSize) Then
        Return SetError($ADO_ERR_INVALIDPARAMETERTYPE, $ADO_EXT_PARAM3, $ADO_RET_FAILURE)
    ElseIf Not $iSize > 0 Then
        Return SetError($ADO_ERR_INVALIDPARAMETERVALUE, $ADO_EXT_PARAM3, $ADO_RET_FAILURE)
    EndIf
......