Rob Earhart's WebLog

Hungarian

(In this post, I demonstrate just how young I am; I'm sure this stuff's been hashed out many times over the years...)

So, I like Hungarian notation.  This puts me at odds with most of my colleagues, who intensely dislike it.  The few times it's come up, though, I'll ask them, "Have you read something by Charles Simonyi on the subject, or are you just reading winbase.h and thinking it looks like useless junk?"  Every time, they've only read winbase.h.  And in winbase.h, it is mostly useless junk, lots of identifiers such as dwFoo and pBuffer, in which the little sprinkling of Hungarian-ish syntax does absolutely nothing to improve the understanding of the reader.

I don't use Hungarian very much, though.

For one thing, in ntdll.dll and in the kernel, that's not the naming convention, and I like to follow the existing style so closely that it's hard to tell from a stylistic standpoint where I've made modifications.

For another... despite the asthetic appeal, the identifiers can be difficult to read.  I wrote some code once which was grovelling a PE's export table, and I wound up with names like rgiipfnNameOrdinals, rgipaszNames, and rgipfnFunctions.  They just don't trip lightly off the fingertips, and they're hard to read, even though they're very easy to break down and understand.

(rgipaszNames, for instance, is an array of image pointers (which need to be translated through the section table to get the offsets to add to the image base to get the actual pointer within the data mapping), and those pointers point to the first characters of zero-terminated strings.  It's not explicit from the names, but the array index can then be used as an offset into rgiipfnNameOrdinals to obtain the index of an image pointer to a function within the image.  That index can be used with rgipfnFunctions to get the image pointer to the corresponding function, and that can be translated to the function.  Clear, eh?  It could be more explicit by creating a type for the name/ordinal array index, maybe "nai" or something, which would then make the identifiers things like mpnaiipaszNames and mpnaiiipfnNameOrdinals, but that doesn't really improve readability; at that point, one would probably want to start inventing more basic types for these arrays, giving the reader more types to memorize in order to understand the code...)


So last weekend, my wife mentioned a study in which someone noticed that people can read words pretty well even when the letters are scrambled, as long as the first and last letters are unaltered, and you have some context to go on--so, you suohld be albe to raed tihs ptrety eislay.

I think this explains a lot about Hungarian, where the exact ordering of the letters matters quite a bit, and the names don't match pre-existing words in the reader's brain.  The reader has to actually slow down and pay attention to all of the letters; the mental mechanism most people seem to have, which is capable of decoding scrambled words given just a few clues, doesn't work.  So the reader's reading speed goes down, and reading comprehension probably drops as well.

For all of its plusses, Hungarian doesn't match the way people think.

(And then there's the whole lack of validation problem, so nothing catches bad Hungarian, and people think dwFoo is a good Hungarian identifier for something which just happens to be implemented as a DWORD, and think Hungarian must be pointless, because comeon, what good is adding a little dw there?)

It'd be nice to see a better naming convention; I don't know of one, though.  I'd love to see better language / development environment support for the sort of semantic typing Hungarian provides.  (If I had my way, languages would support and validate SI units on identifiers, too--it's roughly the same idea.)

In the meantime, I do tend to use a few Hungarian ideas, like the standard qualifiers (so in code I write, Foo < FooLim implies that Foo is usable).  But I don't use Hungarian.

Published Wednesday, January 05, 2005 12:10 PM by earhart
Filed under:

Comments

 

Rick Schaut said:

Take a look at <a href=http://blogs.msdn.com/rick_schaut/archive/2004/02/14/73108.aspx this>. Wikipedia references the article <a href=http://en.wikipedia.org/wiki/Talk:Hungarian_notation here>.

Rick
January 5, 2005 12:34 PM
 

Uwe Keim said:

January 5, 2005 12:40 PM
 

Rob Earhart said:

It wouldn't surprise me if study's a hoax... the underlying idea remains, though--people seem to be able to handle a certain degree of scrambling, but that mechanism's probably not as useful with Hungarian. At least, that matches my intuition, having used Hungarian a bit.

I'd love to see some sort of "reading comprehension" study done on source code written in various languages and in various styles... it'd be hard to factor in people's existing language knowledge, but it might still be useful.
January 5, 2005 12:51 PM
 

Michael Grier [MSFT] said:

I think there is a useful subset of Hungarian.

rgElements - an array of elements
iElement - the index (0-based) of an element
cElements - the count of elements in a collection
rgpElements - an array of pointers to elements
prgElements - a pointer to the head of an array of elements
pElement - a pointer to a single element

specifically, the "i" and "c" prefixes are very useful IMO as a shorthand for "ElementCount" or "ElementIndex".

pElement vs. prgElements is useful to differentiate a pointer to a singleton vs. a pointer to a vector/array/"range" of elements (range is where rg comes from; I think it's obtuse but whatever.)

Further

pszName
rgchName

is a good distinction since the intent is clear that pszName is terminated with a null character where rgchName is just an array of characters which may or may not have a null character inside the array.

In Office, we had to assign a Hungarian prefix to every type which was rediculous. That's where you get some of the craziness.
January 6, 2005 3:04 AM
 

Sorting It All Out said:

January 9, 2005 4:53 PM
 

Sorting It All Out said:

January 20, 2005 3:31 AM
Anonymous comments are disabled

© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker