Jump to content

general programming tips and good habits


Recommended Posts

after using auto-it for some time now i have found i loose myself in my code and and others fine it a bit messy tho i do only program at the hobby level i still want to improve with that in mind i would like a push in the right direction the thing i believe i  struggle with most is the internal code structure ie how large or small should i make a function and how many tasks should i have it complete before i creating a new one how large should a .au3 fire be before calling a second file or should i separate them buy the tasks they do and so on i know this is very basic and comes before the age old hello world program but some how i have missed this lesson in my reading

Link to comment
Share on other sites

For starters, there's this

https://www.autoitscript.com/wiki/Best_coding_practices

Some things I try to keep consistent:

Definitely use Hungarian notation in autoit (the reason I specifically state "autoit" is because in languages like C++ the editor will, usually, catch the error when using the wrong expression on a variable of the wrong type. I.e., multiplying the string literal "1234" by an int 0). This helps because variables can be of any type. Useful in some instances but I find it to be annoying in more cases than not.

; Obvious int type
Local $iArrayIndex

; Probably an int type
Local $arrayIndex

; Obvious Bool type
Local $bMyTest

; Could be string, could be float, could be int, could be bool
Local $myTest

; Button
Global $btnStop

; Maybe bool, could be a string
Global $stop

Const variables are all caps, and I don't use Hungarian on these. Since I usually have less const variables than non const it's easier to remember what it is and, 99% of the time, they're int types (since int variables execute, slightly, faster than any other type).

Always declare and initialize variables at the top of a function. (Sometimes I get lazy and create a temporary variable in the middle of a function but I'll usually go back and move it to the top when I'm done with the function). Initialize so you know that that variable is initialized to something. Sometimes you can create a variable and it will have some weird value.

Always use Local/Global.

Never use magic numbers.

Always release your resources when you're done with them. Especially true for dllstructs, GDI+ objects, and WinApi objects. I remember a project I was not deleting a HBitmap object and my ram shot up to 1gig before the script crashed. In a project that was reaching 2k lines, it was a treat trying to find that memory leak.

Lastly, self documenting functions and variables.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...