Why shouldn't I use “Hungarian Notation”?

Question

I know what Hungarian refers to - giving information about a variable, parameter, or type as a prefix to its name. Everyone seems to be rabidly against it, even though in some cases it seems to be a good idea. If I feel that useful information is being imparted, why shouldn't I put it right there where it's available?

See also: Do people use the Hungarian naming conventions in the real world?

Answer 1

I don't think everyone is rabidly against it. In languages without static types, it's pretty useful. I definitely prefer it when it's used to give information that is not already in the type. Like in C, char * szName says that the variable will refer to a null terminated string -- that's not implicit in char* -- of course, a typedef would also help.

Joel had a great article on using hungarian to tell if a variable was HTML encoded or not:

http://www.joelonsoftware.com/articles/Wrong.html

Anyway, I tend to dislike Hungarian when it's used to impart information I already know.

Answer 2

In Joel Spolsky's Making Wrong Code Look Wrong he explains that what everybody thinks of as Hungarian Notation (which he calls Systems Hungarian) is not what was it was really intended to be (what he calls Apps Hungarian). Scroll down to the I’m Hungary heading to see this discussion.

Basically, Systems Hungarian is worthless. It just tells you the same thing your compiler and/or IDE will tell you.

Apps Hungarian tells you what the variable is supposed to mean, and can actually be useful.

Answer 3

I tend to use Hungarian Notation with ASP.NET server controls only, otherwise I find it too hard to work out what controls are what on the form.

Take this code snippet:

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

If someone can show a better way of having that set of control names without Hungarian I'd be tempted to move to it.

Answer 4

If I feel that useful information is being imparted, why shouldn't I put it right there where it's available?

Then who cares what anybody else thinks? If you find it useful, then use the notation.

Answer 5

Several reasons:

• Any modern IDE will give you the variable type by simply hovering your mouse over the variable.
• Most type names are way long (think HttpClientRequestProvider) to be reasonably used as prefix.
• The type information does not carry the right information, it is just paraphrasing the variable declaration, instead of outlining the purpose of the variable (think myInteger vs. pageSize).

Answer 6

The Hungarian notation was abused, particularly by Microsoft, leading to prefixes longer than the variable name, and showing it is quite rigid, particularly when you change the types (the infamous lparam/wparam, of different type/size in Win16, identical in Win32).

Thus, both due to this abuse, and its use by M$, it was put down as useless.

At my work, we code in Java, but the founder cames from MFC world, so use similar code style (aligned braces, I like this!, capitals to method names, I am used to that, prefix like m_ to class members (fields), s_ to static members, etc.).

And they said all variables should have a prefix showing its type (eg. a BufferedReader is named brData). Which shown as being a bad idea, as the types can change but the names doesn't follow, or coders are not consistent in the use of these prefixes (I even see aBuffer, theProxy, etc.!).

Personally, I chose for a few prefixes that I find useful, the most important being b to prefix boolean variables, as they are the only ones where I allow syntax like if (bVar) (no use of autocast of some values to true or false). When I coded in C, I used a prefix for variables allocated with malloc, as a reminder it should be freed later. Etc.

So, basically, I don't reject this notation as a whole, but took what seems fitting for my needs.
And of course, when contributing to some project (work, open source), I just use the conventions in place!