Framework Design Guidelines: Word Choice


Continuing in the series of discussing topics from the Framework Design Guidelines


Expert from 3.2.5 Word Choice


DO NOT use Hungarian notation.


KRZYSZTOF CWALINA There have always been both positive and negative

effects of using the Hungarian naming convention and they still exist

today. Positives include better readability (if used correctly). Negatives

include cost of maintenance, confusion if maintenance was not done properly,

and finally, Hungarian makes the API more cryptic (less approachable)

to some developers. In the world of procedural languages (e.g., C) and the

separation of the System APIs for advanced developers from framework

libraries for a much wider developer group, the positives seemed to be

greater than the negatives. Today, with System APIs designed to be

approachable to more developers, and with object-oriented languages, the

trade-off seems to be pulling in the other direction. OO encapsulation

brings variable declaration and usage points closer together, OO style

favors short, well-factored methods, and abstractions often make the exact

type less important or even meaningless.


Keep in mind, this guideline is focused on PUBLICLY exposed APIs… so it is ok (even good?) to use Hungarian in your implementation details, but don’t pollute your APIs with them.

Comments (5)

  1. Jon Jagger says:

    Modern IDE’s editors tell you a variable’s type just by hovering the mouse cursor. Strike 1. Hungarian was never , and never will be, a scalable notation. Strike 2. Why have two styles – one for the public and one for the private? Strike 3. Why repeat the type in the declaration and the name of the variable? Repetition and verbosity. Strike 4. In short, there used to be some reasonable(ish) reasons for using Hungarian but I think these reasons now apply much less forcefully (if at all). And surely any Hungarian like notation would have been better as a suffix rather than a prefix? $0.02

  2. Kevin Westhead says:

    Strikes 1 and 4 imply that Hungarian was only used to advertise the type of a variable. This wasn’t the only use, although it was probably the most common. Another use was to advertise the type that a variable worked on rather than the type of the variable itself. E.g. cb for a count of bytes, cch for a count of chars, etc. Both variables could have the same type, such as uint, and the compiler wouldn’t complain if you (accidentally) added them together. Hungarian was useful in highlighting these cases, which might be what Krzysztof was referring to when he wrote "if used correctly".

  3. Jonathan Allen says:

    I feel that the prefixes should imply the use, rather than the type. For example, I often use the prefix s for all strings-like objects, including String, arrays/collections of strings, and StringBuilder.

    The only time it really helps me is when dealing with disposable types. If I use xoSomeObject, I am saying it needs to be disposed in the current method. If I use oSomeObject, either it doesn’t need to be disposed or it doesn’t need to be disposed of here.

    Of course, once VB gets the "Using" keyword, I don’t think I will need that prefix anymore.

    These are all local and member variables. I don’t see the need to use them in the signature.

  4. Keith Patrick says:

    I prefer consistency over all else (except for simplicity/pragmatism), so I make my private APIs of the same style as my external APIs. At one point in time, I used to camel-case my private methods, but after a while (and it may be that during refactoring and newer iterations, methods can change between being public/private) I just opted for a universal (i.e. the public) standard.

Skip to main content