[Off-topic] dbzfanatic:
Writing Code​

Before we get into the actual code writing I want to discuss a few things. Most of them are just tips to make things easier and more readable, especially if you're not the only one working on it.

Naming Conventions

This is simply how you name things. Function names should be pretty obvious and easy to read. If a function reads hex data call it something like ReadHex or HexRead. Variable names should be just as obvious and should tell you what type of variable it is just by the name.

Arrays - start with a (aArray)

Strings - start with s (sString)

Integer - start with i (iInteger)

File - start with f(no floats) or fi(floats)(fFile, fiFile)

Pointers - start with p (pPointer)

Double - start with d (dDouble)

Edit Boxes - start with edt (edtEdit)

Text boxes/Inputs - start with txt (txtInput)

Buttons - start with btn (btnButton)

Sliders - start with sld (sldSlider)

Combo box(dropdown menu) - start with cmb (cbmCombo)

Menu - start with mnu (mnuMenu)

List boxes/TreeViews - start with lst (lstTreeview)

Checkboxes - start with chk (chkCheckbox)

Radio button - start with rdo (rdoRadio)

Labels - start with lbl (lblLabel)

Groups - start with grp (grpGroup)

This will make your code more readable to an extent, and if you break things apart properly that will make it even easier.

Readability:

You always want your code to be readable, if for no other reason than you don't want to forget what something does. If you are working with another coder you definitely want to have readable code, otherwise there will be a lot of time wasted trying to figure out what portions of code do when it would be obvious if it were more readable.

Comments are a good way to improve readability of code, as is breaking code into chunks. Breaking code up should have a negligible effect on speed, if any at all. Here's an example to illustrate my point.

I know these examples aren't great but they do illustrate my point. In the first it's a bit jumbled and somewhat hard to understand what's going on immediately. In the readable version it's clear as to what is happening in the code and in what order. Order does play a key role in coding so it's important to always know what order things happen in. In the autoit example we are taking the ascii value of "a", converting that to hex, then converting that to binary. The example is fairly easy to read but there will be times when things are nested (get to that in a moment) in such a way that it's almost impossible to read. That's why you want to break the code apart, so as to avoid confusion for yourself and anyone else reading your code.

Nested Statements:

Nested statements are basically just statements within other statements. A for loop inside a while loop, a function calling another function (this one happens a lot), etc. More than likely you will use nested statements at some point. This is fine as long as you maintain readability. Always make sure you keep your indentations consistent, a nested statement should be indented one place more than the previous statement. If you have a statement that has 3 parts, 2 nested, there should be 2 indentations. This (broken record :P) maintains readability and makes it simpler to find the portion of code you're looking for. Most compilers/editors do this for you but sometimes not, just make sure everything is there.

Writing Functions:

As I've said before you want your functions to do only one thing, and do it well. Sometimes it's a bit difficult to separate different portions of code into functions but it helps. If you just need part of the code later on it's much better to have it in its own function than to have to run through an entire other function to get to the part you need. This improves speed and efficiency. Take your time, plan out how you want things to flow, and if nothing else wing it. Try different ideas and see what works and what doesn't. I know there are others out there who do their best work when semi-conscious or fully asleep (yes I dream about coding sometimes -_-) but that allows you to think of solutions you normally never would. If you can't get past a roadblock try taking a nap or just plain sleeping. A fresh set of eyes will help with projects, sometimes you need to ask a new coder to look over it and sometimes you need a veteran. Since new coders don't know much yet they often only find obvious errors that we overlook such as an error in syntax or a typo. Veteran coders know a lot and they can help us think of new solutions as well as possibly tell us why what we try doesn't work. When you finally get a function working, look it over. See if there's a way to break it down into even smaller functions.

more soon