by Peter M. Dodge (2 Submissions)
Category: Coding Standards
Compatability: Visual Basic 5.0
Difficulty: Intermediate
Date Added: Wed 3rd February 2021
Rating: 
(4 Votes)
This article explains proper practices regarding variables, naming them, and choosing the proper variable types for the job.
VBcoders
Introduction
A common question a programmer gets from his (or her) peers is how they can improve upon their coding practices. Along with the commenting practices in my previous article, another way which is quite effective is to use variables in a more proper way.
How do I name my variables better?
The first step in naming your variables more appropriately is to move from the obscure a's, b's, and x's of infamy to names such as 'tax', 'longestside', and so forth. Descriptively naming your variables makes it much easier to determine what they are used for and this helps the program to withstand maintainance programmer much better, as the maintainance programmer has a much better idea as to what the variable does, especially when descriptive variable names are coupled with the effective commenting practices discussed in my previous article.
A pitfall of naming variables is that without a standard system they can fall apart very quickly. That leads to our next section,
What naming conventions are commonly used?
Most, if not all, variable naming conventions are based upon variable type, and they are usually 1 or 3 letter prefixes attached to the variable name. The LiquidFire standard is a modified version of the Pascal conventions. I provide it as an example below:
Single: sng (eg sngPi)
Double: dbl (eg dblPopulation)
Integer: int (eg intAge)
Long: lng (eg lngNumAtoms)
Boolean: bln (eg blnSubDone)
Variant: var (eg varUnknownValue)
String: str (eg strFirstName)
User-Defined type: udt (eg udtPlayerInfo)
The common standard has moved more to single letter prefixes (except where the single letter would be duplicated, between the single and string variable types) for convienence, as outlined below:
Single: s (eg sPi)
Double: d (eg dPopulation)
Integer: i (eg iAge)
Long: l (eg lNumAtoms)
Boolean: b (eg bSubDone)
Variant: v (eg vUnknownValue)
String: str (eg strFirstName)
User-defined type: u (eg uPlayerInfo)
In my experience, the three letter convention makes it easier to determine the type of variable, as it is easier to spot and discern. However, this just comes to preference. Use the system that you prefer, but make sure to use it consistently.
What types are appropriate?
Choosing the appropriate variable type to implement is an essential programming skill. The appropriate variable choice is highly dependant on the situation.
When you have to deal with small numbers without decimals, use an integer. When you need small decimal numbers, then use single.
When you need larger numbers, choose a long unless you are absolutely sure these numbers won't include a decimal. Often you can end up with larger numbers with decimals when you don't expect them.
For two-state situations such as on/off or yes/no, simply use a boolean variable. The true/false states of this variable type mirrors such situations well.
Only use a variant type when you are unsure of what data you are going to have to contain, as variants can take up a good portion of system resources. Variant variables are effective in these situations because they can store any kind of data.
When the data is not numerical or boolean (true/false), the only way provided to store it is in a string or variant. In this case, the string variable type is the most efficient way to store data, as it is dynamically resized in memory. This means that whilst the variant type uses as much memory as the largest of the other types, the string variable type uses only as much memory as it needs.
Conclusion
While there are many ways of improving programming techniques, and a very good step after developing effective commenting practices is to develop your variable usage. Descriptive variable names add to the readability of your code and using effective variable types helps make your program more efficient.
Further Reading
if you are interested in further improving your programming practices I can recommend both Code Complete by Microsoft Press and my previous article on commenting practices, "Comments: the Good, the Bad, and the Ugly."
