22

In a now deleted question titled "What naming guidelines do you follow?", the author says:

Also I prefer to code using hungarian notation from Charles Simonyi.

I've run in to several programmers who still prefer to use Hungarian, mostly of the Petzold/Systems Hungarian flavor. Think dwLength = strlen(lpszName).

I've read Making Wrong Code Look Wrong, and I understand the rationale for Apps Hungarian, where domain-type information is included in the variable names. But I don't understand the value in attatching the compiler type to the name.

Why do programmers still persist on using this style of notation? Is it just inertia? Are there any benefits that outweigh the decreased readability? Do people just learn to ignore the decorators when reading the code, and if so, how do they continue to add value?

EDIT: A lot of answers are explaining the history, or why it is no longer relevant, both of which are covered in the article I cited.

I'd really like to hear from anyone out there who still uses it. Why do you use it? Is it in your standard? Would you use it if it wasn't required? Would you use it on a new project? What do you see as the advantages?

Improve this question
4
  • 5
    Hungarian notation was all the rage when I started in IT, but it was a completely coding environment. A Simple text editor no syntax highlighting, intellisense and code files that where several hundred lines in length with all the variables declared at the beginning. It just made life easier in working out what you were dealing with. However with modern tools and practices the need for it has gone in my option and it really should be consigned to history
    – GrumpyMonkey
    Oct 26, 2010 at 17:44
  • 1
    I used that years ago and never liked it much. I don't miss it at all.
    – MetalMikester
    Oct 26, 2010 at 18:58
  • imo the biggest problem with it was using prefixes rather than suffixes - even in apps hungarian the 'wart' usually contains less semantic information than the rest of the name
    – jk.
    Mar 10, 2013 at 8:40
  • 1
    I'm sad for people still not getting the difference between AppsH and SystemsH. SH is history (mostly), AH helps readibility and to avoid failures. No compiler or autocomplete will help to choose the integer variable storing column position, over the integer variable storing pixel position.
    – CLS
    May 4, 2021 at 9:27

8 Answers 8

Reset to default
42

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtFirstName" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.

Update:

I've just read an insightful article (archive mirror) by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

Improve this answer
8
  • 5
    +1 for using quasi-Hungarian to facilitate grouping of UI controls in the IDE. This is the only use that still makes sense for new projects, and I simply couldn't live without it. I often know a control is a textbox, but don't know if it's called "FirstName" or just "Name".
    – Cody Gray - on strike
    Jan 12, 2011 at 1:14
  • 3
    I agree to this answer. About using intValue and strValue, you can also see it as valueAsInt and valueAsStr, so I don't know if I consider this hungarian notation, it is more like that int and str are part of the variable name.
    – Michel Keijzers
    Feb 10, 2012 at 14:25
  • 3
    2 I prefer full suffixes because prefixes can get pretty silly (what is a tssb or a tsddi? Yes, they exist). Abbreviations also have the problem of uniformity, taking TextBox there could be inconsistency about whether it's tb or txt (I have personally seen a 'senior' dev use both on a single window). For 3 I drop the Hungarian when the variable reaches its final intended type (e.g. I would use value and strValue in your example).
    – Jonathan Dickinson
    Nov 20, 2012 at 22:50
  • 2
    Here's a replacement link to Eric Lippert's article: ericlippert.com/2003/09/12/whats-up-with-hungarian-notation
    – Robert K. Bell
    Mar 24, 2021 at 9:28
  • 2
    Best part of this answer: "I constantly review my own practice, so may well do something different as my ideas develop."
    – Jason Weber
    Mar 26, 2021 at 23:02
6

I'm not a huge fan of using hungarian notation but think this way:

  • We can also notice that it's faster to find a string refering to a TextBox in your code: by typing "txt" in your search box.

No imagine the opposite, where every element has its own name. It might be slower for you to find where you want to go, right?

The same goes for ddl when we want to refer to a DropDownList, its easier or not? :)

People won't spend so much time to find where is this element.

The prefix use is not usable for modern languages compilers like C#, but it is usable (readable) for human beings.

Improve this answer
3
  • This is the best example of its practical value that I've heard. (But still not enough to make me adopt it:)
    – AShelly
    Oct 26, 2010 at 16:30
  • 2
    Prefixes were never for compilers, always for people. What has changed isn't the compilers but the IDEs which provide type information and more effective ways to navigate your code.
    – Jeremy
    Oct 26, 2010 at 17:18
  • I'll do the same with variables and (especially) widgets - often giving them short prefixes to denote their type. But not to the point of going "full-out hungarian" on them.
    – GrandmasterB
    Oct 26, 2010 at 18:31
6

Apps Hungarian (tags to denote semantic properties of objects that can't be expressed through the type system) was a reasonable way to deal with some common errors when using the weakly-typed languages of the early 1980s. They serve little purpose in today's strongly-typed languages.

Systems Hungarian (tags to redundantly denote an object's declared type) has never served any purpose except to impose a superficially uniform appearance on a code base. It was created and propagated by non-technical managers, and inexperienced programmers, who misunderstood the intent of Apps Hungarian, and believed that code quality could be enhanced by complex coding guidelines.

Both styles originated within Microsoft. These days, Microsoft's naming conventions categorically say "Do not use Hungarian notation."

Improve this answer
4

The Systems Hungarian notation was in fact a bit of a cock-up, a misunderstanding of the term 'type'. The systems developers took it literally as the compiler type (word, byte, string, ...) as opposed to the apps domain type (row index, column index, ...).

But I guess that every developer goes through several phases of style that seem like a great idea at the time (and prefixing type does seem like a good idea to a novice) before falling into the pitfalls (changing type, creating new, meaningful prefixes, etc). So I guess there's an inertia: from developers that don't get better and realise why it's a poor choice, from developers stuck with coding standards that mandate the practice and from people using <windows.h>. It would be too costly for Microsoft to change to get rid of the prefix notation (which is incorrect in many places: WPARAM?).

Improve this answer
3
  • 2
    Even the intended use is less than optimal because it creates a private type system that the compiler doesn't know about, and therefore can't type check.
    – Larry Coleman
    Nov 3, 2010 at 18:23
  • @Larry: Whilst that's certainly true, there is software available that can parse source code and check the code conforms to a standard. They might be able to ensure that prefixes match in expressions.
    – Skizz
    Nov 4, 2010 at 13:11
  • 1
    My ideal when using static typing is to have the set of compiler types be a superset of the set of domain types. Then the compiler can check everything, no add-ons required.
    – Larry Coleman
    Nov 4, 2010 at 13:33
4

If you come up with the right system of prefixes, you could spread the wear and tear of your keys, which would reduce spending on replacement keyboards.

I suppose I could expand on this. I have used SH at my work place for the last, oh, ten years or so (because it's in our Standard). It has never helped solve a problem.

On the other hand, I have used unadorned but well-named variables in my 'home code' for almost equally as long. I have never missed SH.

In both places, I have written protocol code that requires fixed size primitive types. This is the most beneficial use case I can think of for SH. It hasn't helped that I can tell when written with SH, and it hasn't hindered me when written without SH.

So, in conclusion, the only difference I can see is the wear and tear on your keyboard.

Improve this answer
1
  • 1
    like the sarcasm there :)
    – JohnL
    Oct 26, 2010 at 15:22
4

I actually started using SH in new code I wrote this month.

My assignment involved rewriting some Perl code in JS so it could be moved to the client side of our web application. In Perl, SH is generally not required because of sigils ($string, @array, %hash).

In JavaScript, I found SH to be invaluable to track the types of data structures. For example,

var oRowData = aoTableData[iRow];

This retrieves an object from an array of objects using an integer index. Adhering to this convention saved me quite some time looking up data types. Plus, you can overload succinct variable names (oRow vs. iRow).

tl;dr: SH can be great when you have complex code in a weakly typed language. But if your IDE can track types, prefer that.

Improve this answer
2

I am also curious to see rationale. We know why they used it in the past: lack of IDE support for type information. But now? Simply put, I think it is a tradition. C++ code always looked like this, so why change things? Besides, when you build on top of previous code that used Hungarian notation, it would look quite strange when you suddenly stop using that...

Improve this answer
3
  • 2
    C++ code did not always look like this - check the Bjarne Stroustrup book.
    – JBRWilkinson
    Oct 26, 2010 at 18:16
  • @JBRWilkinson: Charles Simonyi has created Hungarian Notation around 1976 (c2.com/cgi/wiki?HungarianNotation). So this notation actually predates C++. Many if not the most C++ programmers have been using it since the day 1 (of their coding, that is). I understand that Bjarne Stroustrup is notable exception, so is Linus Torvalds, but it doesn't change the facts.
    – Paweł Dyda
    Oct 27, 2010 at 6:56
  • 2
    I think Hungarian was always primarily a Microsoft thing. I didn't see it used much in Unix and Unix-like environments.
    – David Thornley
    Oct 27, 2010 at 21:18
-1

There is one thing people are missing with Hungarian. Hungarian notation actually works GREAT with autocomplete.

Say you have a variable, and the name is intHeightOfMonster.

Say you forget the name of the variable

It could be heightOfMonster or MonsterHeight or MeasurementMonsterHeight

You want to be able to type a letter and get the autocomplete suggest to you some variable names.

Knowing that the heightOfMonster is an int, you just type i and voila.

Save time.

Improve this answer

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