View Single Post
Old 06-01-2002, 04:22 AM
loquin's Avatar
loquin loquin is offline
Google Hound

Retired Moderator
* Guru *
Join Date: Nov 2001
Location: Arizona, USA
Posts: 12,400
Post What's in a Name?

So, why the bother with naming conventions anyway? After all, over 400 years ago, Shakespeare wrote in Romeo and Juliet, "What's in a name? That which we call a rose, by any other name would smell as sweet."

Well, in Will's story, everyone involved knew that Romeo was discussing, (metaphorically, of course,) his lover, Juliet. That's not always the case in the programming arena though. If you were looking at a section of someone else's code and saw a variable named "Rose", what type of variable is it? Does it refer to a color, and should therefore be a long datatype? Or, maybe it is the name of a young lady, and should therefore be considered a string. Or, what about a type of flower, which could have a User Defined Type (UDT) containing common name, latin name, germination period, etc.

To help programmers with this problem, Microsoft programmer Charles Simonyi developed a methodology or naming convention. and detailed the conditions for its use. His naming convention became known as the Hungarian naming convention, due to the fact that the name Simonyi (as well Charles himself) is of Hungarian descent.

Basing his work on that of Simonyi, Gregory Reddick developed a set of conventions for VBA, most of which are appropriate for Visual Basic.

In both Simonyi's and Reddick's standards, the basic convention is to identify a variable name as a Type and a Tag. The Type, always in lower case, is generally a three-character prefix code that identifies the type of data (or an object type) stored within the variable. For example, a prefix of int would identify the variable as an integer; str would represent a string, and txt a textbox. The Tag portion of a variable name represents the data contained within the variable and always begins with a capital letter. LastName, Title, or PhoneNumber, for instance, could represent the Tag. Combining the two fields could result in variable names such as intKeyField, strLastName or txtPhoneNumber, for instance. Microsoft has developed and published a couple of lists of common suggested prefixes as well. The variable and constant list is avaliable here. In addition, their suggested list of objects is here.

Simonyi and Reddick both identify further modifications or enhancements to this base convention, but I won't discuss it further here. Follow the links to their respective naming conventions, above, if you would like to read a more complete discussion of their ideas.

Note that it is not always necessary to apply strict naming conventions in your programs. Simonyi mentions this and discusses those instances. They typically come up when you have written small subroutines or functions that contain a few local variables. In this instance, the scope of usage is small, and the number of variables is also small. Since virtually any programmer should be able to follow and understand what the function is doing after a few seconds study, no further clarification is needed. An example of this is the common use of N or I as loop counters in short Functions or Subs.

So far we've talked about what the Hungarian naming convention is, but very little about WHY we might want to apply it. Essentially, as applications become more complex, the sheer number of variables and constants used within it grow, in both number, and often in complexity. It becomes difficult for the average programmer to keep track of all the variables present in the code. Applying consistent naming conventions like Hungarian notation in your project WILL help you be more efficient in your programming. Just by looking at a variable, at a glance you can tell the type of variable that it holds, and a good idea of what sort of information it holds.

What is more, not only can you tell this information at a glance, anyone who works on the code with you, or reviews your work, or who maintains the code can as well.

"I don't have any other people who are working with me, and I know my own code, so I don't think this naming junk will help me," you may be thinking. Well, while that may be so, what about when you open that program you wrote two years ago, and haven't had to look at since but someone (maybe you) uncovered a subtle bug in it. You'll have a real learning curve on your hands. Even though you wrote it, it WILL take you some time to understand what you wrote earlier. I've been there, and done that. Applying a consistent naming process will do nothing but help you.

Even though you currently might work alone, you may need to work with others on a large project in the future. When multiple programmers are involved in working on a project, naming conventions become even more critical. You will be reviewing the other programmer's code, and they will be reviewing yours.

"Since I'm not working with anything very large yet, why should I start trying something new? I can pick it up when I'll need it on a larger project" A few weeks ago, I had the opportunity to walk through the Band Practice Room at my daughter's school. A large sign on the wall reminds the music students that "Practice Makes Permanent, only Perfect Practice Makes Perfect." I really feel that this applies in our situation also. I've noticed that as I have made concerted efforts over the years to improve and to be more consistent in my programming style, it has become almost second nature to do so. It has gotten to the point that I rarely have to even think about it any more.

A common error for beginners (and sometimes for those more experienced ) is to give a variable the same name as a standard function/sub name. This is a poor practice for two reasons. First, it is extremely confusing when trying to troubleshoot the application. Secondly, you lose the function or sub that you have renamed. It has been redefined, and the original function isn't available for use. So, for instance, if I were to name a variable Sqr, I couldn't use the square root function in my code. By following a standardized naming convention, you are unlikely to name one of your variables with the same name as an existing sub or function.

One last point in favor of learning, and more importantly, applying consistent naming conventions in your code is a very pragmatic one; I, as well as many senior programmers and analysts in the industry, are actively involved in the selection of new programmers at our places of employment. Typically, I get the opportunity to interview all the folks who are applying for a programming position in my (IT) department. During these interviews, I have a set of questions that I will ask all the applicants, and I will ask them to write a small program for me which will perform a simple task - maybe display data from an Access table on a form. When I look at their code, naming conventions are one of the things that I look for, and I know that I'm NOT the only one who does this. It just makes good business sense. After all, what if I have to pick up a project for one of my co-workers when they quit, or have a baby, or break their leg, or any of a whole number of possibilities?

So, after all, what IS in a name?
"I have my standards. They may be low, but I have them!" ~ Bette Middler
"It's a book about a Spanish guy called Manual. You should read it." ~ Dilbert
"To understand recursion, you must first understand recursion." ~ unknown

Last edited by loquin; 10-21-2004 at 05:27 PM.
Reply With Quote