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. Use the prefixes m_ and g_ to differentiate between module and global scope, and an abbreviation to give an object’s data type. For example, the following statement defines a module-scope PictureBox variable:




Private m_picCanvas As PictureBox

Routine names are generally MixedCase .

Many developers carry these rules a bit further and add type prefix abbreviations to all variables, not just objects. For example, this statement declares an integer variable:




Dim iNumEmployees As Integer

If you apply these rules strictly enough, you should never need to assign one variable to another variable’s value, unless the two have the same type abbreviation. If you see a statement that mixes variable types, you should examine the code more closely to see if there is a real data type mismatch problem. For example, the following statement should make the developer suspicious because it’s assigning an Integer value to a Long variable.




mlngNumEmployees = intNumAbsent + intNumPresent

Some developers extend the rules to cover all programming objects, including functions and subroutines. For example, a global function that returns a string might be named gstrGetWebmasterName .

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

Generally, this scope and type information is more important the farther you are from a variable’s declaration. If you declare a variable inside a subroutine, a developer can usually remember the variable’s data type. If there is any doubt, it’s easy to scroll up and review the variable’s declaration.

In contrast, if a variable is declared globally in an obscure code module that developers rarely need to read, a programmer may have trouble remembering the variable’s scope and data type. In that case, using prefixes to help the developers’ memory can be important.

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 tells you what the value means (and variables with such terrible names are all too common). The name mblnDataIsLoaded is much more descriptive. I have never seen a project that suffered because it lacked variable prefixes such as mbln . On the other hand, I have seen developers waste huge amounts of time because the descriptive parts of variable names were confusing.

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/default.aspx?scid=kb;en-us;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.

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.

Flylib.com

Category list

Similar pages

Naming Conventions

Naming Conventions

Similar products