Do people use the Hungarian Naming Conventions in the real world?

Question

Is it worth learning the convention or is it a bane to readability and maintainability?

Solution 1

Considering that most people that use Hungarian Notation is following the misunderstood version of it, I'd say it's pretty pointless.

If you want to use the original definition of it, it might make more sense, but other than that it is mostly syntactic sugar.

If you read the Wikipedia article on the subject, you'll find two conflicting notations, Systems Hungarian Notation and Apps Hungarian Notation.

The original, good, definition is the Apps Hungarian Notation, but most people use the Systems Hungarian Notation.

As an example of the two, consider prefixing variables with l for length, a for area and v for volume.

With such notation, the following expression makes sense:

int vBox = aBottom * lVerticalSide;

but this doesn't:

int aBottom = lSide1;

If you're mixing the prefixes, they're to be considered part of the equation, and volume = area * length is fine for a box, but copying a length value into an area variable should raise some red flags.

Unfortunately, the other notation is less useful, where people prefix the variable names with the type of the value, like this:

int iLength;
int iVolume;
int iArea;

some people use n for number, or i for integer, f for float, s for string etc.

The original prefix was meant to be used to spot problems in equations, but has somehow devolved into making the code slightly easier to read since you don't have to go look for the variable declaration. With todays smart editors where you can simply hover over any variable to find the full type, and not just an abbreviation for it, this type of hungarian notation has lost a lot of its meaning.

But, you should make up your own mind. All I can say is that I don't use either.

---

Edit Just to add a short notice, while I don't use Hungarian Notation, I do use a prefix, and it's the underscore. I prefix all private fields of classes with a _ and otherwise spell their names as I would a property, titlecase with the first letter uppercase.

Solution 2

The Hungarian Naming Convention can be useful when used correctly, unfortunately it tends to be misused more often than not.

Read Joel Spolsky's article Making Wrong Code Look Wrong for appropriate perspective and justification.

Essentially, type based Hungarian notation, where variables are prefixed with information about their type (e.g. whether an object is a string, a handle, an int, etc.) is mostly useless and generally just adds overhead with very little benefit. This, sadly, is the Hungarian notation most people are familiar with. However, the intent of Hungarian notation as envisioned is to add information on the "kind" of data the variable contains. This allows you to partition kinds of data from other kinds of data which shouldn't be allowed to be mixed together except, possibly, through some conversion process. For example, pixel based coordinates vs. coordinates in other units, or unsafe user input versus data from safe sources, etc.

Look at it this way, if you find yourself spelunking through code to find out information on a variable then you probably need to adjust your naming scheme to contain that information, this is the essence of the Hungarian convention.

Note that an alternative to Hungarian notation is to use more classes to show the intent of variable usage rather than relying on primitive types everywhere. For example, instead of having variable prefixes for unsafe user input, you can have simple string wrapper class for unsafe user input, and a separate wrapper class for safe data. This has the advantage, in strongly typed languages, of having partitioning enforced by the compiler (even in less strongly typed languages you can usually add your own tripwire code) but adds a not insignificant amount of overhead.

Solution 3

I still use Hungarian Notation when it comes to UI elements, where several UI elements are related to a particular object/value, e.g.,

lblFirstName for the label object, txtFirstName for the text box. I definitely can't name them both "FirstName" even if that is the concern/responsibility of both objects.

How do others approach naming UI elements?

Solution 4

I think hungarian notation is an interesting footnote along the 'path' to more readable code, and if done properly, is preferable to not-doing it.

In saying that though, I'd rather do away with it, and instead of this:

int vBox = aBottom * lVerticalSide;

write this:

int boxVolume = bottomArea * verticalHeight;

It's 2008. We don't have 80 character fixed width screens anymore!

Also, if you're writing variable names which are much longer than that you should be looking at refactoring into objects or functions anyway.

Solution 5

It is pointless (and distracting) but is in relatively heavy use at my company, at least for types like ints, strings, booleans, and doubles.

Things like sValue, iCount, dAmount or fAmount, and bFlag are everywhere.

Once upon a time there was a good reason for this convention. Now, it is a cancer.

View more solutions

Comments

[Mark Cidade]

I use firstNameLabel and firstNameTextBox

[Anzurio]

I recommend reading blogs.msdn.com/larryosterman/archive/2004/06/22/162629.aspx

[justjoe]

what happen ? and how i start to become a cancer?

[mibollma]

"With todays smart editors where you can simply hover over any variable to find the full type, and not just an abbreviation for it, this type of hungarian notation has lost a lot of its meaning." What if you consider sites like pastebin.com, stackoverflow, any board with code tags or even web based repository browsers? In this case i find those prefixes just as useful as in a crappy editor. In fact it's the main reason im still using it.

[Lasse V. Karlsen]

I still think that prefixing a variable i for integer is pointless, the name of the variable should be far more expressive than the single i.

[Ally]

"I don't use neither" means you use both.

[Daniel Sokolowski]

It's a huge benefit whend debuging as well, treat it as the 'intent' of the expected type stored.

[vasilescur]

typedef volume_t int; typedef area_t int; typedef length_t int;