Do you prefix variable names with an abbreviation of the variable types? (Hungarian Notation)

Question

In my current job, there are no coding guidelines. Everyone pretty much codes the way he wants. Which is fine, since the company is small.

However, one new guy recently proposed to always use Hungarian Notation. Until now, some of us used some sort of Hungarian Notation, some of us didn't. You know, it's an engineering company, so coding styles do not really matter as long as the algorithms are sound.

Personally, I feel that these little type abbreviations are kind of redundant. A well thought-out name usually delivers the same message. (Furthermore, most of our code has to run on some weirdo DSPs, where a concept like bool or float doesn't exist anyway).

So, how do you feel about Hungarian Notation? Do you use it? Why?

Answer 1

When most people say "Hungarian Notation" they're actually talking about "Systems Hungarian".

Systems Hungarian is completely useless and should be avoided. There is no need to encode the type of the variable in it's name. However, Systems Hungarian is actually a misunderstanding of the original, "real" Hungarian: Apps Hungarian.

In Apps Hungarian, you don't encode the "type" in the variable name, you encode the "kind" of the variable. So not nWidth, but pxWidth or emWidth (for "width in pixels" or "width in ems" respectively). Not strName but sName or usName (for "safe name" or "unsafe name" respectively - useful when accepting input from users: unsafe strings).

Personally, I don't usually bother with either. Unless I'm doing something that is explicitly converting the "kind" of a value (for example, I've used the "px" and "em" prefix in the past because it makes mistakes like pxArea = emWidth * emHeight obvious).

See also, Joel's article, "Making Wrong Code Look Wrong."

Answer 2

pronounYou verbShould adverbNever verbUse adjectiveHungarian nounNotation, prepositionIt verbMakes collectivenounEverything adverbSo comparativeBloody adjectiveHard infinitiveTo verbRead.

Answer 3

Firstly:

You know, it's an engineering company, so coding styles do not really matter as long as the algorithms are sound.

Coding styles do matter regardless of the company. Yes the algorithms have to be sound, but the code must be maintainable by everyone not just the original developer. Having a coding standard that includes style elements goes some way to achieving that. I'm not saying all the code should be identical in style - that would be counter productive, but there should be a degree of consistency.

Now onto Hungarian notation:

While it had its uses, with a modern IDE that supports IntelliSense type behaviours it's not necessary to include the type of the variable in its name. This information is available to you in other ways. At worse it can make the code harder to read if you have to change the type of the variable in the future.

Answer 4

Don't use it. It is redundant and makes code harder to read.

Answer 5

A lot of the debate about (System) Hungarian Notation depends on the area of work. I used to be very firmly on the side of "no way!", but having worked for a few years at a company where it is used for embedded development I can see some advantages of it in certain applications and it has definitely grown on me.

Systems Hungarian

From what I can tell, Systems Hungarian tends to be used a lot in the embedded field. In PC applications, the compiler will deal with a lot of the issues associated with the differences between (e.g.) strings, integers and floating point values. On a deeply embedded platform, you're more often concerned about the differences between 8-bit unsigned integers, 16-bit signed integers etc. The compiler (or even lint with MISRA rules enforced) doesn't always pick up on these. In this case having variable names like u8ReadIndex, s16ADCValue can be helpful.

Apps Hungarian

Apps Hungarian has definite advantages when it comes to PC/Web applications, for example offering a visual difference between 'unsafe' strings and 'safe' strings (i.e. those entered by a user and those that have been escaped or read from internal resources or whatever). The compiler has no knowledge of this distinction.

What's the Point?

Use of (Systems or Apps) Hungarian is all about making wrong code look wrong.

If you're copying an unsafe string straight into a safe string without some escaping, it'll look wrong if you use Apps Hungarian.

If you're multiplying a signed integer by an unsigned integer, the compiler will (often silently) promote the signed one to (a possible enormous) unsigned one, possibly resulting in an error: Systems Hungarian makes this look wrong.

In both of these situations the (Apps/Systems) Hungarian notation tends to make formal code reviews quicker as there is less referring back to the type of the variable.

Overall

Overall, my opinion is that the most important thing is that you have a coding standard. Whether that uses Systems Hungarian, Apps Hungarian or neither is a matter of personal or group preference, much like choice of indentation types etc. However, there are definite advantages to the whole development team working to the same preference.

Answer 6

The purpose of Hungarian Notation is to encode information into the identifier that cannot otherwise be encoded in the type system. My own opinion is that if this information is important enough to be encoded, then it's important enough to be encoded in the type system, where it can be properly checked. And if the information is not important, then why the heck do you want to clutter up your source code with it?

Or, to put it more succintly: type information belongs in the type system. (Note: it doesn't have to be a static type system. As long as it catches the type errors, I don't care when it catches them.)

A couple of other answers mentioned Units of Measure as acceptable uses of Hungarian Notation. (I'm kind of surprised that noone mentioned the NASA Mars Climate Orbiter yet, since that seems to come up all the time in discussions about Hungarian Notation).

Here's a simple example in F#:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Look, Ma, no Hungarians!

If I were to use Hungarian Notation instead of types here, that wouldn't help me one bit:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

The compiler let it straight through. I am now relying on a human to spot what is essentially a type error. Isn't that what a type checker is for?

Even better, using the Frink programming language:

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

So, in summary: I don't like Hungarian Notation. You should never use it.

That being said, I think using Hungarian Notation is a good idea. Wait, what?

Yes! In this particular case, you mentioned:

Furthermore, most of our code has to run on some weirdo DSPs, where a concept like bool or float doesn't exist anyway

But that is precisely the only sensible use case for Hungarian Notation!

---

PS: I wholeheartedly recommend looking at Frink. Its manual contains some of the most awesome fart jokes ever. It's also a pretty cool language :-)

Answer 7

It doesn't make sense in an object orientated language - everything is a type which is apparent when trying to use it.

Answer 8

Purpose of an identifier is more important than its type. If you use descriptive names for identifiers in your programs, you don't need to use Hungarian notations. isConnected is always more readable and easy to understand than boolConnected.

Answer 9

The only place where Systems Hungarian is waranted is with a weakly typed language like C. It's doubly important with C because there is no explicit object (it has structs, but all functions are external to the struct). In something more strongly typed like C++, Java, and C# it doesn't help, and in fact makes things worse. Code changes, and it is a lot easier to change a type than it is to change all the places you are using a variable name. It's also unnecessary busywork that tends to get ignored.

If you have units of measurement, it might help to encode that in a name--but in the end that can also be extra noise. For example, we will declare the standard unit of measure for the different things we are working with in our code. For example, are we using gradients or degrees, meters or feet, frames or milliseconds? Once the standard is set for the code, any time we read in one unit of measure, we always convert immediately to the standard unit of measure for the code.

My advice: start with your current pain points and pick a reasonable standard for that part of the code. Overspecifying a coding standard is counterproductive. There's a lot of value in having variable and field names that spell out what they represent, and most of the time you can safely infer the type from the concept.

Answer 10

HECK NO!

Don't use Hungarian notation or any other notation. As programmers, we shouldn't be using "notation" for our variable names.

What we should do is name our variables well:

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.

• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.

• When zeroing in on how general or specific a name should be, consider the domain it is in and the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then it is fine to come up with a prefix or suffix to denote that difference. Keep it as short as possible.

As other answerers have said, it is this narrow case that started "Apps Hungarian", to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft! In fact, why not use Jörg W Mittag's idea of making an actual new type out of it? Then you can't possibly get things mixed up.

In almost any area, adding stuff that has minimal meaning density reduces the overall meaningfulness and ease of comprehension. Here's one example from Ben Franklin. And another example: it is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

By adding information, I made that a complete pain to read.

So forget notation. Forget special prefixes that you always add. In my opinion, the only real guideline here should be:

Keep variable names as short as possible, as meaningful as necessary, and always unambiguous.

Answer 11

We used Hungarian back when I was a C++ programmer, and it was great. You could see the type of a variable (f.e. BSTR, CString, LPCTSTR, or char*) without searching for the declaration. In those days, you would search for the declaration by doing:

1. ctrl-home
2. ctrl-F
3. variable name
4. enter

So it mattered quite a bit. But somewhere around 2000, a few things happened:

• editors became intelligent enough to display the variable type as a tooltip
• editors had a "go to declaration" shortcut, and a quick way to browse back
• C++ was used less, and most other languages have less variable types. For example, in C#, you're pretty sure lastName is a System.String, because there's only one string class.

I was one of the last to switch away from Hungarian, and now when I read old source code, it actually annoys me.

Answer 12

I just hate the hungarian notation, I prefer using underscores to delimiting variable names.

On top of that, when you put the type as first letter at the begining of your variable name like this: float fvelocity; vect vDirection; string ** ppszWord;

autocompletion sorts them all, and you have trouble finding what you want, and people tend to use what they think is better, and it's not a notation anymore.

I just like to write ThingsLikeThat when I need to be very descriptive about the variable, because it saves space and the fact there are caps makes it more readable.

What I usually do, is name my methods and classes with the first letter being Uppercase, and lowercase for variable names, and an underscore for variable names (I find this last one useful).

Seriously I prefer people to care about those rules: Use commas, arithmetic and braces with relevant spaces:

void f(int a, char b);
int a = b + 4 / (3 + 4);

No more than 80 char per line, or AT MOST 90 chars, use multi-line arguments for functions or long if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

Answer 13

Agree with most, it's an old style.

With modern IDE's, a quick hover over a variable shows you the type.