Home -> Programming -> Processing -> Identifiers

Identifiers

Identifiers are those things in a program which we must name. They include all variables, all constants. all controls, all procedures, and all functions that we create. To make sure that VB is clear about our use of identifiers there are rules for naming them. These rules enable the language to repsond to our programming in specific ways. They prevent confusion.

Naming Identifiers

We create and name an identifier by declaring it. This process is slightly different depending on which of the identifiers we are creating and so will be shown for each type separately. There are several rules that must be followed, and then there are some conventions which should be followed when naming identifiers. Lets deal with rules first. These rules apply to all declarations: variables, constants, procedures and functions. Any time we declare an identifier we must follow these rules. If we don't the VB editor will flag it as an error. The rules are:

  • All identifiers must begin with a letter or an underscore.
  • Identifiers can only contain letters, numbers and the underscore character. No spaces or punctuation are allowed.
  • In VB the maximum size for an identifier is 16,383 characters. (Practically speaking 32 characters is the recommended limit after all a word that is 32 characters long is a very long word.)
  • The name cannot be a reserved word. This is a word that has a special meaning in Visual Basic and can not be used for any other purpose.
These above rules must be followed, but beyond this there are several conventions or suggestions for naming variables which will make hte programmers life easier if they are followed. I have listed these below.
  1. Name the identifier for the data it holds, or the purpose it serves, and do not abbreviate so much that another person is left uncertain as to what the abbreviation means.
  2. Use a prefix or suffix which identifies the data type of the information stored in the variable or control. See the discussion below on Hungarian Notation.
  3. Keep your identifier names as short as is practical. There is no utility to creating really long names.
  4. Watch your pluralization. Use it only when it makes sense!

Hungarian Notation

In earlier versions of VB it was suggested that new programmers use Hungarian Notation in naming their variables. Hungarian Notation is a set of shorthand prefixes which immediately remind the reader of the code exactly what data type the variable holds. In large programs it becomes impossible to remember this information, so the programmer has to look up the declaration from time to time. For example if we have a Textbox which we want it to hold a person's first name, a good legal identifier would be firstName, adding the Hungarian prefix, txt for Textbox, would cause the name to be: txtFirstName. The main advantage of this system is that the datatype of the variable, or control, is instantly obvious; the disadvantage is that it is one more thing to remember when creating our object names. But, it saves the programmer from looking up the declaration every time they forget what data type firstName holds.

Recently this practice has come under criticism and from my point of view undeservedly so. For example most programmers define many variable as objects and many have observed that sticking obj if front of all of them really doesn't help at all. I agree, but there is no need to throw the baby out with the bath water. I recommend you follow Hungarian Notation practice for all simple variables and all controls, but not for things like objects, collections and other complex variables. The new suggestion is to use a suffix so that my previous example of a first name would become firstNameTextbox. My problem with this convention is two fold. First, names are much longer with this convention and so there is always more typing or increased use of the auto-complete feature of the editor. Second, it has the same failings as Hungarian Notation when it comes to our object variables. So what have we really gained. Whichever way you see this discussion, I strongly recommend that you follow one convention or the other. The benefit is well worth the small effort to learn the habit of using a data type prefixes or suffixes.