That doesn't seem to make sense.

In local variable, we sort of know the type anyway. It's local. We're working on it.

Yet in function name or global variable, the definition is very far away on other files. It seems that hungarian notations make far more sense there.

For example, in objective-c I used this

+(CGFloat) fHeightOfNavigationController

So when I want to know the height of navigation controller, I will need to press a button that specify the function.

What's the button? What's the name of the function. Is it heightOfNavigationController? Is it NavigationControllerHeight? Is it navHeight?

I don't know which letter I should type first to activate the autocomplete. But I know the function is float.

So I just type f...

Tada... I got fHeightOfNavigationController in autocomplete.

Yet I don't think this is how most people use hungarian notation.



2 Answers 2


hungarian isn't used all that much anymore for various reasons, most importantly code completion software solves most of the problems hungarian aimed to solve.

also hungarian in it's original format (apps hungarian) specified the usage of the variable instead of just the type (systems hungarian). Meaning that the coordinates of the mouse cursor on the screen would be scrXmouse and scrYmouse instead of imouseX and imouseY.

A function to transform it to local view could then be named translateScrXScrY2LocXLocY(int srcX, int scrY, int* locX, int* locY); then you immediately see when you made a mistake in variable order

  • 2
    hmm, IMO the fact that it makes for stale names when refactoring is far more important than code completion. Got to love LPFSTR in the Win32 and Win64 APIs when long pointers and far strings have been meaningless concepts for something like 20 years.
    – jwenting
    Mar 12, 2014 at 10:49
  • @jwenting What do you mean by "stale names" during refactoring? Do you mean that a non-Hungarian variable name doesn't need to change if its type changes during refactoring, but a Hungarian name would have to change? If I change the type from String to an object, the Hungarian variable name would change from String strStatus to MyStatus objStatus, for example. Apr 9, 2023 at 3:37
  • @NickAlexeev yes, and that's a major PITA, and more often than not doesn't happen. The Microsoft Windows API for example is chock full of things that have the wrong name for their datatype as a result of this.
    – jwenting
    Apr 9, 2023 at 9:22

People don't use Hungarian notation any more, its a nice idea that's had its day.

Everyone knows the problem with Hungarian - apart from making your names garbled with a special code - if you change anything, you then also have to change the name to match. So if you have a function called iGetCustomer and one day you want to return more than just an integer, you have to change everywhere the function is called to be cstGetCustomer which is just a nuisance. (though, obviously, you have to change everywhere its used anyway as you've changed the return type!)

Still, its just one of those fashion things, nobody uses it any more, instead they use a form of name coding where some types are notated differently (eg interfaces with I prefix, exception classes with 'Exception' suffix etc).

WRT intellisense, many people type this. and then let the system present a list to pick from. If you also name according to function rather than return type, you can then group your functions (eg GetX, GetY, etc will all appear together whereas iGetX and fGetY will not).

  • 4
    Not quite true. People do still use Hungarian notation. Systems Hungarian has problems. Functional Hungarian has valid uses. Mar 12, 2014 at 8:51
  • and it never was a nice idea anyway, especially systems hungarian (functional has something going for it but makes refactoring very hard, especially in public APIs).
    – jwenting
    Mar 12, 2014 at 10:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.