NAMING CONVENTIONS

Many development teams adopt naming conventions to make their code more consistent and easier to read. Different groups have developed their own conventions, and you cannot really say that one of them is best. It doesn’t really matter which convention you adopt. What is important is that you develop some coding style that you use consistently.

One rather simple convention is to use lowercase_letters_with_underscores for variables with routine scope, MixedCaseLetters for variables with module and global scope, and ALL_CAPS for constants of any scope. For example, the following statement defines a module-scope PictureBox variable:

Private Canvas As PictureBox

Routine names are generally MixedCase.

Many developers carry these rules a bit further and add type prefix abbreviations to control names. For example, the following code declares a PictureBox variable:

Dim picCanvas As PictureBox

Some developers add scope prefixes (m for module, g for global), and some also add type prefixes to variables other than controls (such as iNumEmployees for an integer) and even to subroutine names (as in gstrGetWebmasterName for a global function that returns a string). Visual Studio’s IntelliSense will tell you a variable’s data type if you hover the mouse over it so these more complex prefixes are not as useful as they were before IntelliSense became so powerful. For that reason this type of prefix is much less common than it used to be.

No matter which convention you use, the most important piece of a name is the descriptive part. The name mblnDL tells you that the value is a module-scope Boolean, but it doesn’t tell you what the value means (and variables with such terrible names are all too common). The name DataIsLoaded is much more descriptive.

Building an all-encompassing naming convention that defines abbreviations for every conceivable type of data, control, object, database component, menu, constant, and routine name takes a lot of time and more space than it’s worth in a book such as this. For an article that describes the conventions used by Microsoft Consulting Services, go to http://support.microsoft.com/kb/110264. It explains everything, including data type abbreviations, making the first part of a function name contain a verb (GetUserName rather than UserName), and commenting conventions. That article was written in 2003 and common usage changes over time, but the article can give you a place to start in defining your own naming conventions.

Naming and coding conventions make it easier for other programmers to read your code. Look over the Microsoft Consulting Services conventions or search the web for others. Select the features that you think make the most sense and ignore the others. It’s more important that you write consistent code than that you follow a particular set of rules.