Website Design United States, Website Design California, Website Designing United States, Website Designing California

Naming Conventions

Are naming conventions really necessary when programming?

There is a lot of debate over this topic. Are naming conventions really worth it? Aren't they a hassle to learn and use? Can't you code quicker if you don't using naming conventions?

If you’re not familiar with naming conventions, here is how they work.

When most people hear of naming conventions, they automatically think of Hungarian Notation. (HN) If you have seen naming conventions before, but are not familiar with the term "Hungarian Notation", you are probably familiar with how it looks.

Hungarian Notation is a naming convention invented by Charles Simonyi from Microsoft. Some examples of HN are: m_nSize, hwndParent and lpszFile.

Traditional Hungarian Notation uses various prefixes to identify the scope and type of a variable.

Lets examine the following variable in C++.

lpszFileName

The lp designates this is a Long Pointer.
The sz designates this is a string.
The File is the name of the variable.

So, in reading the variable lpszFileName, you would read it as "a long pointer to a string holding the file name". If that variable were of a module level scope, it would be prefixed with 'm_'. So the module level version of that variable is: m_lpszFile.

There are several advantages to using HN. As we just saw, using HN tells us the scope and type of a variable, without using a very long variable name. It also means you can figure out what type of variable is used, even when reading printed code. Basically, using a naming convention is an extension of commenting. It allows you to understand what a variable is for, just by reading the name.

There are some disadvantages to using naming conventions though...

First, what happens when you change a variable type? You have to go change ALL the instances of that variable within your code. Some editors have some pretty sophisticated find-and-replace tools, so this wouldn't be that big of an issue... but it still needs to be done.

Second, what happens if you upgrade your language, and what was a 16-bit integer is now a 32-bit integer? Now you have to go change portions of your code so your naming convention still fits...

Third, naming conventions can defeat the purpose of encapsulation. Encapsulation means "black box" right? So why does the programmer need to know what specific type is being returned? They just create a variable of that class, and then use it. Who cares if it’s a long, or a string, or an object.

So, do the disadvantages outweigh the advantages? No... I would still use naming conventions for the simple fact of readability. As I stated before, using naming conventions in your programming allows you to read your variable types (and their purpose) at a glance... No need to go looking for a declaration.

My style:

I prefer to use an abbreviated version of the HN. I generally use a single letter prefix for types, a single letter prefix for scope (with the procedure scope having no prefix) and no underscores.

So a module level string variable would be named like this: msFileName.

Here is a listing of some naming conventions I use. Not all of them port over to every language... and not every language has type variables. But these can be ported fairly easy from language to language.

Prefix Type

s String
c Character
t Byte
b Bool
i Integer
l Long
f Float (single)
d Double
cur Currency
dte Date / Time
o Object
v Variant

As you can see... I try to stick to a single letter prefix. But in some cases, this is not an option if you want to keep the prefixes logical.

For scope, I use only two prefixes:

Prefix Scope

m Module level
g Global

I rarely use global variables or objects anymore... I try to avoid them, simply for OO reasons... but that is another topic in itself... :)

I also use a naming convention for all controls. I use a three-letter prefix for controls. Here are some of the prefixes I use:

Prefix Control Type

txt Text box
lbl Label
cmd Command Button
chk Check Box
opt Radio button (option button)
lin Line
lst List box
cbo Combo box/dropdown box
fra Frame
mnu Menu

Logical Object Names

Now we get into syntax behind your object name. I say object, since this logic also applies to controls, forms and classes.

When naming your objects, there are a few things you need to keep in mind.

First, the name should be descriptive of what that object contains or does.

For example:
sFirstName // Good
sSomeData // Bad

The first object would appear to be a string to hold the First Name. This provides dual functionality. First, as stated, its descriptive of what the object is for. Second, other people reading your code can easily figure out what that object is, just by the name.

The second object appears to hold Some Data. What is Some Data? It’s a string… but what is it used for?

Second, your objects should be named consistently.
iNum // Good
iNo // Good - just inconsistent with the first style

Either example is fine (I prefer the first) but you need to use that same name in other places. Don’t call the variable iNum in one routine, and call it iNo in another… and iNumber in yet a third… be consistent.

Finally, you want your object names to be short. You don’t want to spend all day typing in a name. So keep them clear, yet concise.

Oh, and watch your spelling… even though it is code, and you may be the only one who ever sees it… don’t misspell your object names.













 


© 2008-2009 dotnet4all.com