Introduction
I'm going to give you a little warning right from the start. The use of naming conventions is a religious issue for many programmers - sometimes ranking as high as the age-old goto debate or the choice of language. Some like naming conventions and some hate them. Most large programming organizations, however, do use them. I also think that many of those that passionately hate having naming conventions imposed on their work would probably (perhaps grudgingly) admit their usefulness.
Like many other "standards", what's more important than any particular naming convention, is that you choose a naming convention and use it faithfully. While you can probably get away with using your kids names for variable names in a 100 line program, you're inviting chaos if you take that approach with any serious application.
I will state one thing as a rule up front. Use Option Explicit. If you're new to Visual Basic and not familiar with it - its a feature that requires you to declare each variable in your program. Without Option Explicit, every time you type a new variable name, VB will create a new variable for you. As you can imagine, this can create bugs that are extrememly difficult to find if you happen to mistype a variable name somewhere. Other than pure laziness, there's simply no excuse for not using Option Explicit, so I have absolutely no sympathy for you if you ever have a bug caused by letting the compiler create a variable you didn't intend to create.
In the rest of this page, I'll describe the standards I've used for naming procedures, variables, and other objects of various types. Feel free to use my convention or invent your own.
Choosing Identifier Names
Most of the papers and books I've read that cover naming conventions spend a lot of time covering things like prefixes for different data types, etc., and neglect to cover the most basic concept - creating a good name for an identifier. Sure, it can help to use variable data type prefixes, but it doesn't help much if the name of your loop counter is intBunny and the procedure that contains the loop is called strDoSomething.
If you've done a decent job designing the application and the code, it doesn't take much effort to come up with decent names for the identifiers. The only problem that you're likely to run into is that the names may become excessively long. While very long names can be tiresome to use, its my opinion that you're better off to take the time to type an extra character or two than to use a meaningless or hard to interpret name.
Let's take a look at an example of how using appropriate variable names can help you write better code. Have you ever seen something like this:
For i = 0 To 10
For j = 1 To 100
List1.AddItem x(j, i)
Next
Next
Its more likely than not that in this case the array indexes have been reversed inside the inner loop. The programmer probably meant to do this:
List1.AddItem x(i, j)
Its easy to eliminate this problem before its created by giving the loop indexes more meaningful names:
For iDivisionIdx = 1 To iDivisionCount
For iDistrictIdx = 1 To iDistrictCount
lstCustomers.AddItem sCustNames(iDivisionIdx, iDistrictIdx)
Next ' iDistrictIdx
Next ' iDivisionIdx
There's no confusion now over what loop index we're dealing with. Not only has the problem of transposing the indexes been elimiated - the entire loop construct is easier to read and understand because the names reflect the data being used.
Here are a few things to consider when naming identifiers in general:
- Use a name that represents the data or the function.
The name chosen should represent the data being used. If you are creating a variable that represents the total number of employees, EmployeeTotal or EmployeeCount would be good names. - Use abbreviations consistently.
While its not necessary to have variable names that are 30 characters long, don't go overboard in abbreviating names. "Tm", for example, is only two characters shorter than "Time" and much less readable. There some common tags that are often used, such as Num for Number, Idx for Index, and so on. Feel free to use these if you wish, but if you do, use them consistently. Don't use Num some of the time and Number or Count at other times. - Make the name readable.
A good rule to apply here is that you should be able to read your code to someone over the phone and have them be able to write it down without asking you for spellings. - Use a noun for variables.
Pick a word that represents the data. This will make the code somewhat self-documenting and considerably easier to read. - Use a noun and a verb for procedures.
If a procedure performs an action on an object, use a verb describing the action and a noun describing the object. For example, if a procedure adds a new contact to a database, "AddContact" might be an appropriate name. - Use caution with temporary variables.
This is an area that can often cause problems such as the loop index error shown earlier. You may often need a temporary variable, such as a loop index or dummy variable to hold a return value from a function that you don't need. However, consider this: There's really no difference between a temporary variable and any other type of variable. They are all temporary since they only exist in the memory of the computer while the program is running and are always an abstraction created for the benefit of the programmer. The computer doesn't care what name you use, so why not take the time to type an extra character or two and use a meaningful name.
Naming Procedures
In a large, complex program, you may have hundreds or thousands of procedures. Using a naming convention and good identifiers can make your job of finding and using the procedures considerably easier.
One standard that is commonly used for procedure names is to use a verb describing the action performed followed by a noun describing the object acted upon. I have to say that I'm not particularly fond of this convention, mainly because it makes it difficult to find a procedure in an alphabetical listing. If you are using "Get" as a prefix to functions which return values (such as GetWindowText), you'll end up with a long list of GetThis and GetThat procedures. I've always thought that it makes more sense to use the same technique but to reverse the noun and the verb. GetWindowText would become WindowTextGet. This groups all the procedures associated with a particular object together. Unfortunately (for me anyway), I'm probably the only person to have attempted to use such a convention - so make your own choice to be consistent with the rest of the world or make up your own standard. Perhaps something else entirely works best for you.
Regardless of the naming convention you choose, there are a few things which a procedure name should do for you:
- Use a name that represents an object and an action.
Whether you use verb-noun or something else, the name of the procedure should indicate what the procedure does and what it does it to or with. - Be consistent in the order of the words.
If you're going to use verb-noun, always use verb-noun. If you mix and match the two, you're only making your own life harder. While you may be able to remember all of the procedure names in a program with 100 procedures, you are unlikely to accomplish the same feat in a program with 1,000 or 10,000 procedures. - Be consistent in the verbs and nouns used.
Just as you should be consistent when naming variables, you should also be consistent when naming procedures. If you're going to use SetFirstName, also use SetLastName rather than AssignLastName.
There's one other thing I'll mention which crosses the line between a coding standard and a naming convention. A well written procedure should do one task. If it does this, it will be easy to create a name for it. On the other hand, if the procedure does six things to four different objects, you may end up with a name like "AddCustomerAndUpdateRepPhoneAndFaxNumber". If you end up with a procedure name that looks like a run-on sentence, you probably haven't written a good procedure. If you need a name like "DoABunchOfStuff", you've almost certainly written a poor procedure. Before fudging a half-baked name, take another look at the code.
Naming Variables
Clearly its important with variables, just as with procedures and all identifiers, to use a name that is readable and representative of the data in use. There is, however, a debate among programmers over the use of various means of identifying variables by data type and usage. Some programmers like to use prefixes to identify the data type of the variable, while others prefer to use type declaration characters, and still others use neither and omit data type identification from the name entirely. The closest thing you'll find to a "sanctioned" naming convention for variables can be found in the MSDN/Visual Basic Starter Kit on the VB4 Professional edition CD under Visual Basic Programming Conventions from Microsoft Consulting Services.
I happen to like using data type prefixes, although I don't follow the Microsoft standards in all cases. Here's why:
- The code is easier to read.
I find that type declaration characters distracting when reading a code listing and difficult to verbalize. - You aren't bound to VB's data types.
If you wish to define "hWnd" as a prefix for window handles, you can do so without breaking the standard. - You can design your own standard.
The convention published by Microsoft specifies using "int" as a prefix for integers. I happen to prefer using just "i" - it saves a fair amount of typing for one of the most frequently used data types without sacrificing readability. - Some of the data types introduced in VB4 have no type declaration character.
While I don't expect VB to drop the type declaration characters entirely in future versions, I also don't expect type declaration characters to be supported for any future data types. Also, many of the variables you work with are object variables which also have no type declaration character.
There are two other notable sets of tags I use for variable names.
The first is a prefix indicating the scope of the variable. I use "m" for module level variables and "g" for global variables. These tags not only identify the scope of the variable but also avoid name collisions and name shadowing between variables at different scopes.
The second is a prefix for parameters. I use this to avoid naming collisions between parameters and local variables and to distinguish between input and output variables. Input parameters are prefixed with "p" and output with "rp".
By using these additional modifiers, I can normally be sure that I never two variables in scope with the same name.
Modifier Tables
Here are most of the modifiers I use, grouped as follows:
- Data Type Modifiers
- Scope Modifiers
- Miscellaneous Modifiers
- Control Tags
- DAO Objects
Data Type Modifiers
The data type modifiers are prefixed to the variable name. | Data Type | Modifier |
| Boolean | f |
| Integer | i |
| Long | l |
| String | s |
| Byte | b |
| Single | sng |
| Double | dbl |
| Date/Time | dt |
| Currency | cur |
| Variant | vnt |
Scope Modifiers
The scope modifiers are used before all other prefixes. | Scope | Modifier |
| Global | g |
| Module | m |
Miscellaneous Modifiers
| Modifier | Item |
| v | Variant
This is used with normal data type prefixes to indicate that a variant is being used but a specific data type is expected. For example, in a database application a foreign key might normally be a long (l) but may also be Null, thus the use of a variant. The resulting prefix would be vl. |
| p | Procedure Parameter
This prefix is used to help avoid name collisions when working with local variables and procedure parameters which otherwise share the same name. This modifier is prefixed to the base data type modifier. |
| rp | Return Parameter
Used to indicate output (return values) passed through the parameter list in a procedure. This modifier is prefixed to the base data type modifier. |
| t | User Defined Type
This modifier is used to indicate that the variable is a user-defined data type. It precedes all but the scope modifier. |
| _a | Array
This modifier is appended to the variable name and is used to indicate that the variable is an array. |
| F - frm | Form
The single upper case F is used in form names as specified at design time. The frm tag is used for variables representing forms. For variables, this tag follows the scope modifier. |
Control Modifiers
These tags are used in control names and in variables representing controls. | Tag | Control Type |
| chk | Check Box |
| cmd | Command Button |
| cbo | Combo Box |
| dat | Data Control |
| dir | Directory List Box |
| drv | Drive List Box |
| fil | File List Box |
| fra | Frame |
| hsb | Horizontal Scroll Bar |
| img | Image |
| lbl | Label |
| lst | List Box |
| opt | Option Button |
| pnl | 3D Panel |
| pic | Picture Box |
| txt | Text Box |
| tmr | Timer |
| vsb | Vertical Scroll Bar |
| Windows 95 Controls |
| il | Image List |
| lv | List View |
| sb | Status Bar |
| tb | Toolbar |
| tv | Tree View |
Data Access Objects
These tags are used with DAO objects and precede all but the scope modifier. | Tag | DAO Object |
| ct | Container |
| db | Database |
| fld | Field |
| grp | Group |
| idx | Index |
| prop | Property |
| qd | QueryDef |
| rs | Recordset |
| rel | Relation |
| td | TableDef |
| usr | User |
| ws | Workspace |
Given the number of available objects, custom controls, etc., that are available for use in Visual Basic, it would be impossible to come up with a comprehensive list of tags for every type of object. For those not listed (or maybe for those that are as well) you'll need to come up with your own tags. What's more important than using any particular set of tags is to choose a convention for the names and use it consistently. You're sure to be kicking yourself if you go back and look at your code after six months and discover that half of your Byte variables and half of your Boolean variables are prefixed with "b".
Summary
That was a lot to take in, but don't let yourself be confused or intimidated by the number of different modifiers and rules I use in naming objects. Once you get used to using a convention like this it becomes second nature and really does make life easier by allowing you to recognize the nature of the object by merely reading the name.
I'll repeat this again - it doesn't really matter what particular naming convention you choose as long as you name objects consistently. There's enough to learn and do in writing an application without expending excess effort in deciphering poor object names. Using a naming convention will eventually become automatic and that ultimately saves effort because its one less thing to think about.
Note: I have also published a Database Object Naming Conventions page. You might find it helpfull.
Originally written by Joe Garrick
