Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

A Proud Hungarian [Notation] Heretic

If I still use Hungarian Notation, am I a programming pariah?  A Hungarian heretic?  Part of the Axis of Programming Evil?


Here is why I use Hungarian Notation (HN):



  1. I can quickly determine the type of a variable by glancing at it (I don’t have to hover over the variable with the mouse or anything)

  2. I can quickly determine the scope of a variable by glancing at it (the _ for class level, etc).

  3. Our existing code base uses it, and I’m anal about consistency and code uniformity

  4. I’ve been doing it for so long I seem to “think“ in HN; it comes naturally to me

I know HN is out of fashion and critics say it obscures the meaning of the code.  I’ve always been a contrarian so I don’t care if “all the other cool programmers“ use a style that I don’t; and I don’t feel it obscures my code.  Given the following code that doesn’t use HN:



DataObject.Save( name, birthday ) ;


It may be close to real English, but my analytical side wants more structure.  I wonder: is “name“ a string?  a structure encapsulating both first and last names as strings? a more complex object with first, middle, and last name strings . . . along with culture info etc?  As for “birthday” the possibilities are more numerous: a DateTime?  a simple Date?  a verbose string for a date (like Tuesday, November 30th 2004); it could even be a boolean indicating if the birthday is today or not.  You get the idea.


So, revisiting this with Hungarian Notation we could have:



DataObject.Save( strName, dtmBirthday ) ;  //string and datetime


or



DataObject.Save( strName, dteBirthday ) ;  //string and date (not using time component)


or



DataObject.Save( strName, blnBirthday ) ; //string and boolean


And so on . . .


Now, I don’t discredit other coding methods — I’m just explaining my position on Hungarian Notation.  Use what you’re most productive in (even Klingon Notation if you want — which reminds me of this great Klingon post from a while back).  I think the key element to a coding style is consistency.  When maintaining code written by others, I can get up to speed quickly when there was some standard employed.  If you don’t do it for yourself, then think of the children.  Those who come after you will thank you for it. 


I just finished some enhancements to an application written by another company; the app was well designed.  Yes, I avoid jumping on “the previous people who worked on this sucked!“ bandwagon . . . unless they really sucked, that is.  It was smooth sailing except for their failure to name user interface controls in any style — they just left the designer defaults so we had a huge array of Textboxes named TextBox1(n) or TextBox1, TextBox2 and so on for 30 or more controls (it was a good old tabbed user interface, so lots of room for controls).  This was pervasive throughout the whole 25+ form application.  And no, I don’t think leaving controls named to their defaults to be a “style.“  That’s just lazy.  Give me a “txtTitle“ and “txtSSN“ any day!

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to A Proud Hungarian [Notation] Heretic

  1. skyshadow says:

    you might wanna check this out:

    http://ootips.org/hungarian-notation.html

  2. skyshadow says:

    never liked HN a bit. i agree with what Darron said. there will come a time when somebody, someday will forget to change the prefix when changing the datatype due to refactoring.

  3. Hendry says:

    One great benefit of hungarian is that it can group the same type of object/type in the intellisense list. If you have a list of strings like this: sBla, sFoo, sAbc, … then when you’re in need of quick searching of the list of an object/type (string in this case), you just do intelisense starts with s…

    If you don’t use Hungarian, BlaString, Foo, Abc, whatever, you’ll need some efforts to get that in the intelisense lists.

  4. Greg Postlewait says:

    I use HN only for local, disposable variables (i, tempS, etc.) but really discourage it for business objects and other structures. C#, Pascal and so forth are very natural language languages and naming conventions should (IMHO) lend themselves be self-describing. Source code is your lowest level of application documentation.

    That being said, I usually still capitalize all my globals and constants….

  5. Darron says:

    Your point is valid until some refactoring changes datatypes of these variables, and some idiot forgets to do the "rename" refactoring as well.

    So now I’ve been working with code with the wrong hungarian prefix… (quickly fixing that by the way)

    This was nice to walk in on as the new guy. Everyone else didn’t seem to mind it.

    Hungarian is a bad habit that I never appreciated. We’re much better off without it.

  6. Darrell says:

    I agree with code consistency, although I don’t tend to use Hungarian Notation much. Default names are good for quick hack-em-up apps or apps with few moving parts, but after that there has to be SOME sort of naming convention.

  7. Dave says:

    For the most part, I agree with you and use HN most of the time. I’m also a huge stickler about code consistency. However, it should only be used *internally* to a method or class; never on anything public. Your example of DataObject.Save(name, birthday) is actually the correct way, especially if you are abiding by the Microsoft .NET Design Guidelines and using FxCop to check your work. Run FxCop against that method call with HN and it will yell at you.

    Also, DataObject.Save(name, birthday) is more correct from an API perspective. If you use DataObject.Save(strName, dteBirthday), it still looks like your public interface is in code when cognitively is should be more english-y. Steven Clarke has some good posts on API design (http://blogs.msdn.com/stevencl/).

Leave a Reply