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?

  • See also: programmers.stackexchange.com/questions/14789/…
    – Kramii
    Jan 25, 2011 at 11:31
  • 8
    What programming language are you using? Jan 25, 2011 at 13:50
  • 3
    Actually its not fine - you ought to have a coding standard (formal or otherwise), in my opinion its never fine... but others may disagree.
    – Murph
    Jan 25, 2011 at 14:48
  • @Larry: We are using mostly C and C++, with a smattering of Assembler and Lua here and there.
    – bastibe
    Jan 25, 2011 at 16:05
  • 12
    @Paperflyer, coding standards / rules are not for the customers, they are for the development team. Unless you believe the same developers will be on staff forever (unrealistic), I strongly believe you should establish and follow coding standards. It leads to more maintainable systems, gets new staff members up to speed quicker, and more consistency. That being said, I agree that Hungarian notation has proven redundant, and are more a relic of the past. Well thought-out names are more important, especially with the much more powerful IDEs in use these days. Jan 25, 2011 at 16:35

13 Answers 13


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."

  • 2
    Check out Simonyi's writing on the subject: He's the original promulgator of Hungarian, and his version is the one that's useful. msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx Jan 25, 2011 at 11:55
  • 1
    There should be some way to include units in a custom type if you really need it (same for safe/unsafe strings). However, I can see that you could run into performance issues doing that (you wouldn't want to wrap a float in a class, for instance). In F# it introduces the unit of measure feature, which is basically adding extra type information to doubles, just for this purpose. Jan 25, 2011 at 15:59
  • 1
    In code dealing with user input I find it useful to prefix user-data with raw i.e. rawUsername
    – zzzzBov
    Jan 25, 2011 at 16:07
  • 1
    @Scott another option would be a strongly typed typedef
    – jk.
    Jan 25, 2011 at 17:11
  • 1
    @JBR: Did you actually read the answer? In "Apps Hungarian", the s is not for string or something, but for "safe" (or I've also heard "safe string").
    – user7043
    Jan 25, 2011 at 22:17

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

  • 6
    Made me smile... pedantry, but "to" is a preposition, not an infinitive. "to read" is an infinitive.
    – DrAl
    Jan 25, 2011 at 15:13
  • @dral of course, it was in the humourous register, not the grammar freak's :D Jan 25, 2011 at 15:23
  • 1
    That was awesome, made me laugh. :)
    – Corv1nus
    Jan 25, 2011 at 21:12


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.


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

  • 8
    It's worse than "redundant". For some complex situations, it's difficult to get right. Specifically, each of the classes you define in your app needs an abbreviation. After defining 20 or so classes, you're out of one-letter abbreviations. What now? A mixture of one-letter and two-letter? What about complex references to an element of a data structure? Pointer to array of mappings of lists to mappings from integers to strings? How would an abbreviation of that be helpful?
    – S.Lott
    Jan 25, 2011 at 10:52

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, 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.

  • You should make it clear what languages you are talking about. Since you are working with embedded development I assume you are using C? Hungarian does make sense in C, but not in more modern languages.
    – JacquesB
    Nov 29, 2015 at 17:56

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 :-)

  • I'd vote this up 50 times if I could. Jan 25, 2011 at 16:10
  • 1
    Very interesting argument! I might just try that in my current project. typedef meter float...
    – bastibe
    Jan 25, 2011 at 16:14
  • 1
    @bastibe You mean typedef float meter?
    – Wolf
    Feb 27 at 10:11

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


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.

  • 2
    I absolutely agree! This is what they call 'App Hungarian' as opposed to 'System Hungarian'.
    – bastibe
    Jan 25, 2011 at 10:39
  • @bastibe: Nope, this is what they call descriptive names. Apps Hungarian relies on abbreviations.
    – JacquesB
    Nov 29, 2015 at 17:52

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.

  • 1
    Actually, good IDEs (or plugins) usually have pretty powerful refactoring capabilities which can change variable names with ease.
    – bastibe
    Jan 25, 2011 at 13:33
  • 4
    Understood, but the extra noise in version control for name changes doesn't help things either. Let's just say the value added doesn't justify the overhead of maintenance. Jan 25, 2011 at 13:40
  • will depend on the language as well as some have direct support for stongly typed UoM or stongly typed typedefs
    – jk.
    Jan 25, 2011 at 15:52


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.

  • This is almost exactly what our standards are. The only difference is that we prefer Pascal Case when naming things so that Capitalization is consistant.
    – DForck42
    Jan 25, 2011 at 21:10

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.


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:

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

Agree with most, it's an old style.

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

  • 3
    I find this (that the IDE helps) a poor argument - when you're coding, yes, you will have that benefit. But there are any number of cases (committing, reviewing, diff/blame, etc) where you may not have that support available.
    – Murph
    Jan 25, 2011 at 14:51
  • Your're wrong!!!!! ;) Fair point, I still wouldn't user Hungarian though!
    – ozz
    Jan 25, 2011 at 16:27
  • @Murph but why not doing all of those in the IDE as well?
    – Ooker
    Jul 27, 2023 at 5:46
  • 1
    @Ooker at the time I wrote the comment (12+ years ago) the tooling support in an IDE was not nearly at the level it is now - and for a code review it can still be a challenge. I also think that you should be able to review code on paper (in theory, not really in practice) because that means that you can understand it just by reading it - and that has high value.
    – Murph
    Jul 27, 2023 at 10:23
  • I still wouldn't use it ;-)
    – ozz
    Jul 27, 2023 at 14:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.