THORNSTA Posted April 30, 2016 Share Posted April 30, 2016 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 More sharing options...
InunoTaishou Posted April 30, 2016 Share Posted April 30, 2016 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. Synapsee 1 Link to comment Share on other sites More sharing options...
mikell Posted April 30, 2016 Share Posted April 30, 2016 Reading how the sentences are organized in post #1 makes easy to understand why the problem is huge ^^ czardas 1 Link to comment Share on other sites More sharing options...
Xandy Posted May 1, 2016 Share Posted May 1, 2016 13 hours ago, mikell said: Reading how the sentences are organized in post #1 makes easy to understand why the problem is huge ^^ We have a lot in common already OP and I. Human Male Programmer (-_-) Xandy About (^o^) Discord - Xandy Programmer MapIt (Tile world editor, Image Tile Extractor, and Game Maker) Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now