Local Variable Naming

In the second post of my Code Naming Conventions series I’m going to explore how we could name our local variables. One of the nicest things about local variables is that their scope is quite limited. If the functions, methods and properties in your classes are kept short and readable you will find that tracing local variables back to their definition point is not very difficult. Just because It’s easy to search out a variables definition that doesn’t mean that you should neglect the way you name them. Having your local variables named consistently from one function to the next and having the naming convention work well with the naming of classes, functions, module level variables and other items will make reading your code easier. It all comes down to the developer consumer, or future owner of your code, knowing what to expect in certain circumstances.

I have seen a number of different naming conventions for local variables and I’m sure there are ten times more than that. As I’ve said before, none of these are right and none are wrong. The one thing to know is that no matter which of these naming conventions are implemented they will not make up for poorly named or overloaded variables. A variable named Cat should never contain a Dog. Naming conventions can neither rectify nor prevent this from occurring. That task resides firmly in the hands of the developer.

camelCasing
The Practical Guidelines and Best Practices book recommends using camelCasing for local variables. This keeps your code quite clean and leaves no doubt what the semantics of the variables are. One of the major drawbacks with *Casing conventions is that more than one is usually implemented together (if the programming language allows you to, which C# does and VB.NET does not). This can lead to some very difficult to trace bugs. By separating the semantics of two variables solely based on the casing of their names you have increased the amount of thinking that a developer has to do and the amount of information that they have to retain.

In short, camelCasing for local variables will create clean looking code, but you have to watch for case sensitive languages creating semantic differences based solely on capitalization.

private void camelCasing()
{
   //Good use of camelCasing
   int countOfItems;
   string firstName; 

   //Bad use of camelCasing
   //It’s far to easy for a developer
   //  to incorrectly use one or the
   //  other variables and have no
   //  compile time checking.
   //This is not possible in VB.NET
   int countOfCows;
   int CountOfCows;
}

Hungarian Notation
The most verbally abused variable naming convention of them all, Hungarian notation, must still be included in this list. Most books (including both that I’m referencing) and people scoff at Hungarian as a throw back to days past when programmers had to work with much poorer tools than we have today. Like every other naming convention there are some good and bad points to this convention. One of the worst things that Hungarian notation does is overloading of the name of a variable. By adding a prefix indicating the variable type you have now tied that variable to both programmatic and business domains. It can also be argued that the convention prevents you from changing the variable’s type without altering it throughout the codebase. Some would argue the opposite of that and say that changing the variable’s type should require you to revisit its use throughout the codebase as a way to ensure the proper use of the variable with it’s new type. One of the most common arguments against Hungarian notation is that modern development environments provide alternate methods (such as mouse-over tooltips) to determine the type of a variable. The opposite of this argument is that using Hungarian notation provides instantaneous feedback with no need to make mouse movements.

In conclusion, Hungarian notation adds some clutter to your variable names, but it can improve the readability of the code.

private void HungarianNotation()
{
   //Hungarian notation
   string strFirstName;
   int intCount;
   MyCustomClass objSomeName = new MyCustomClass();
}

Single Letter Hungarian
This is a variant of Hungarian notation that I have used while working with one lead developer. The practice of Single Letter Hungarian (it may have some other name that I don’t know) is to prefix all variables with one single letter which indicates the variable’s type. Like Hungarian notation, this naming convention adds some extra clutter to your codebase. Unlike Hungarian notation, that clutter is 1/3 the size. One of the biggest issues that surfaces when using this convention is that you are limited to 26 prefix characters and you will inevitably run into conflicts. An example is the use of the letter ‘s’ for both short and string types. The only way around this is to select a different letter for one of the two types and use it consistently. Unfortunately this will still result in reduced code readability.

Single Letter Hungarian notation is a compromise between the ease of type identification and the additional code clutter of prefixes. Unfortunately the 26 letter prefix pool is a significant drawback to the useability of this naming convention.

private void SingleLetterHungarian()
{
   //Single Letter Hungarian Notation
   string sFirstName;
   int iCount;
   
   //Problem area.
   string sAmount;
   short sCurrency;
   //Less readable option for short types
   short hCurrency;
}

SCREAMING CAPS
This naming convention is rarely used but bears mentioning for a couple of reasons. One of the great things about SCREAMING CAPS is that variables will stand out very clearly when you are reading the code. Although they stand out from the surrounding code, variables following this convention and having compound words in them are not as easily read as those using the *Casing formats. The one place that SCREAMING CAPS has found a home is in the naming of constants. The code still has the same readability problems as I just outlined for SCREAMING CAPS used on variables, but using this naming convention on constants will keep them very distinguishable from variables.

While capitalization plays a role in all naming conventions, SCREAMING CAPS is less readable than strategically capitalized letters.

private void SCREAMINGCAPS()
{
   //SCREAMING CAPS notation that is difficult to read.
   string FIRSTNAME;
   int COUNTOFCOWS;
   MyCustomClass SOMECUSTOMCLASS = new MyCustomClass();

   //SCREAMING CAPS notation for constants
   const string ACONSTANTVALUE = “blah”;
}

My Choice
At one time or another I have worked with all of these naming conventions. As I’ve outlined above all have their good and bad points. For a number of reasons my personal preference is to use Hungarian notation. Now that I’ve got all your hackles up let me explain why.

One of the benefits of Hungarian notation is that it provides you with instant variable type feedback. I can hear your moans and exclamations that I can get that by mousing over the code or looking for the definition (either manually or by right clicking and selecting Definition). The truth is, I’m a keyboard jockey. The less I have to use my mouse the better I am. If I have to mouse over or right click and select Definition to determine the type of a variable I feel like I’ve just wasted some productivity, perhaps even dropped out of ‘the zone’ slightly. If I use Hungarian notation I can read my code and say “Yep, strFirstName is a string”. My hands are still on the keyboard and I’m on my merry way.

The second reason that I favour this naming convention is because of the one thing it doesn’t let me do. Although I can easily change the type of a variable from string to int, my variable now looses context. Like the good little programmer that I want to be, I can not allow the following to appear in my code.

int strCount;

I want to refactor out the incorrect prefix so that I adhere to the naming standard (variable prefix matching the variable type). I know that you are thinking that I now have the painful task of changing that variables name everywhere that it’s being used. I like that I have to do this. Now I must revisit the use of the variable in all situations to change the variable name, and while I’m doing this I can ensure that I haven’t introduced any unforeseen problems in the code.

Another reason that I like Hungarian notation is that I am much less likely to run into the situation where I have two variables that can only be distinguished by their casing. For me the probability of this happening is further decreased because I use camelCasing and PascalCasing for anything that is publicly exposed by my function, class or framework (more on that in future posts).

The only time that I will stray from Hungarian notation is in the case of constants. For constants I use the SCREAMING CAPS notation. I find that if I don’t, I have difficulty visually identifying constants from variables when I’m reading code.

Hopefully this fhas given you some food for thought.