It's Hungarian-esque

by Michael S. Kaplan, published on 2005/01/09 15:53 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/01/09/349538.aspx

The other day I was reading Rob Earhart's post on Hungarian and four things occurred to me:

1) Rob is right about the fact that in the kernel mode code that is not the naming convention they use.

4) Most of my teammates use it all the time, despite their claims to the contrary.

I remember conversations where I would point out that a pointer to string length would be a pcchName, not a cchName and gotten the automatic answer of "oops, you're right" rather than a comment about how awful/ugly Hungarian is.

And I can look in our .NET Framework source code and see how many times dtfi is used for DateTimeFormatInfo objects, nfi is used for NumberFormatInfo objects, and ci is used for either CultureInfo or CompareInfo objects (maybe if they spent more time with Hungarian they would have resolved the naming conflict in the ci type abbreviation!).

A lot of Hungarian has disappeared from parameter names in our code just like in the rest of the .NET Framework, but I honestly do not buy the arguments for it (typical argument -- we have Intellisense now!) since I usually do not use Visual Studio as my source code editor (it is not so great for indexing large projects) and it does not help with source code diffs, thus I get no direct benefit from Intellisense.

Lack of Hungarian for me just means more time needed to figure out what stuff is.

Hell, when I owned wizard source code for Microsoft Access, a lot of the new VBA code I wrote there used Hungarian even though VBA had Intellisense because it still did not help in the diff-ing department.

And when you own anything with over 80,000 lines of code (especially code owned by over 10 other developers across five versions of a product!), any trick to make part pf it easier to understand is welcome. And others did a lot of it anyway, with db as a Database and rs as a Recordset, and a zillion cch and ich variables.

With that said, anything can be overused, as Michael Grier pointed out in his comment to Rob's post -- some teams, like Office, would require a Hungarian prefix for every type, whether it would make sense or not.

I guess that may make me less popular with the legions that say they prefer to avoid Hungarian notation for their code at all costs. Oh well, I am sure they will get over it, especially since they are probably using it anyway. :-)

Heh, you have the same reasoning as I do, intellisense is not helpful. It's all very well arguing that an object should describe itself by its own structure and not it's name, but you are then relying on a tool to help you work out what an object is.

( Being a link whore, I wrote about this at http://idunno.org/displayBlog.aspx/2004061901 )

Larry Osterman had an interesting post about Hungarian notation a few months ago. Basically, he made a distinction between strict and informational notation (he used a better and more self-speaking terminology).
My opinion is that a little Hungarian is very helpful as opposed to strict use (ala Office team, according to you) makes it so unreadable that it becomes useless.

Well, I'd never accuse Larry of being less descriptive. :-)

I just noticed the same thing Michael Grier did, Office might be better now (I hope so!).

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.