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.
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 NextIts 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 ' iDivisionIdxThere'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:
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:
I happen to like using data type prefixes, although I don't follow the Microsoft standards in all cases. Here's why:
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.
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.
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.
Used to indicate output (return values) passed through the parameter list in a procedure. This modifier is prefixed to the base data type modifier.
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.
This modifier is appended to the variable name and is used to indicate that the variable is an array.
|F - frm||
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.
|dir||Directory List Box|
|drv||Drive List Box|
|fil||File List Box|
|hsb||Horizontal Scroll Bar|
|vsb||Vertical Scroll Bar|
|Windows 95 Controls|
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".
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