uncategorized

Module Variable Naming

As part of my Naming Conventions series I’m going to discuss the naming of module level variables. Naming conventions for module level variables are quite similar to those you might use for naming local variables. Rather than regurgitate the same information that exists in my previous post on Local Variable Naming, I’m going to concentrate on how to differentiate module level and local level variables.

The list of naming conventions considered for use at the module level is usually quite similar to those considered for use in local variable situations. This list can include camelCasing, PascalCasing, Hungarian Notation, Single Letter Hungarian and SCREAMING CAPS. Being able to differentiate between module and local variables and consistency between different naming areas (i.e. Local and Module) are usually the primary factors considered when selecting the convention.

Differentiating between module and local level variables can be accomplished in a number of different ways. Below I will outline a few of those ways and the benefits and dangers each may pose.

Underscore Prefixing
I have worked on a number of projects where the module variables were prefixed with the underscore character. This convention accomplishes the two important factors of easy identification and consistency with other conventions. Underscore prefixes clearly indicate that a variable has been defined at the module level. The use of the underscore also can be used as an extension of the local variable naming convention employed. In this way it allows for all variables, module or local, to employ the same naming convention.

1
2
3
4
5
6
7
8
9
10
11
12
//Underscore Prefixing
//combined with camelCase
string _firstName;
int _cowCount;

//combined with PascalCasing
string _FirstName;
int _CowCount;

//combined with Hungarian Notation
string _strFirstName;
int _intCowCount;

“m” Prefixing
Like the Underscore Prefixing convention, I have worked with “m” Prefixing as well. “m” Prefixing also shares a lot of features with Underscore Prefixing. Instead of prefixing your module level variables with an underscore you would prefix with a lower case letter “m”. This convention also offers a number of benefits, but also has some drawbacks. “m” Prefixing allows for the consistent use of a single variable naming convention across local and module level variables. One of the problems with using the letter “m” as a prefix arises when the standard naming convention has leading lower case letters such as camelCasing and Hungarian Notation. When this occurs, the “m” prefix will tend to blend into the overall variable name which reduces it’s effectiveness as a quick identifier of module level declaration.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//“m” Prefixing
//combined with camelCase
//note how the “m” does not clearly stand out
string mfirstName;
int mmachineCount;

//combined with PascalCasing
string mFirstName;
int mMachineCount;

//combined with Hungarian Notation
//note how the “m” does not clearly stand out
string mstrFirstName;
int mintMachineCount;

camelPascalCase/PascalCase
Unlike the last two conventions, this is a combination of two naming conventions. The combination of camelCasing and PascalCasing leverages the case sensitivity available in some programming languages. Because of it’s reliance on case sensitivity, this convention will not work in VB.NET, but will in C#. To employ this convention you must choose one of the two *Casings for use at the local variable level and the other will then be used for module level variable naming. One of the benefits of this convention is that you have no cluttering of the code space with extra characters. There are a couple of problems with this convention. The first issue is that there the difference of one letters casing is not an easily recognizable identifier of module level declaration. Another issue is that by employing two naming conventions, one for local variables and the other for module variables, you have increased the responsibility of the programmers declaring variables. Programmers can easily implement reversals of the correct naming conventions (i.e. using PascalCasing when camelCasing is called for). In addition to these problems, programmers also can make mistakes in their usage of the variables if both local and module defined variables differ only by case. It is entirely possible, and quite probable, that a programmer will, at some point, work with the incorrect variable simple because they did not case the variable as they intended. Issues like this can create very difficult debugging exercises as no compile time validation of this occurrence can be preformed.

My Choice
After having used all three of these conventions I have found that I get the best results from using the Underscore Prefixing convention. I find that it is very easy to identify a module level variable when it is used at any point in the codebase. I also am fond of how it can lead to using only one naming convention (Hungarian Notation is my personal choice) with the slight addition of an underscore.