Years ago, I got a task to add features to the source code of an existing application. It originated in a company that was seemingly obsessed with win32-style programming and Hungarian notation.
After a while, the m_lpsz, g_u32 and s_aul prefixes started to make sense, and almost immediately after that, they stopped making sense.
Here’s what some say about Hungarian notation:
- Bjarne Stroustroup: “is completely unsuitable for a language that supports generic programming and object-oriented programming”
- Linus Torvalds: “Encoding the type of a function into the name is brain damaged”
- Microsoft .NET naming conventions: “DO NOT use Hungarian notation.”
The fact is, the times when it had a function are long gone. The purpose of it was to be informative about the variable or function type. It was supposed to be helpful, so that when you needed to change the variable type, you had to go through all instances where it has been used and skim through the code to make sure it still performs its intended function with the new type.
Today, showing the variable type is the responsibility of the IDE. When you mouseover on a variable (or even as you type it in), a decent IDE already tells you what the variable type is or what is the return type of a function. And when you change the name of a variable, even if it’s Hungarian, what you’ll probably do is a project-wide search and replace.
The person who originally came up with it at Xerox, moved on to work at Microsoft, and they later abandoned its use. Nowadays it still seems to resurface here and there. I seriously hope no one’s teaching it.
When it comes to readability, which one is easier to read (an actual example, for some reason, this company did not believe in vowels):
BYTE **alpszInpts(BYTE *p_lpszTStrDvcNm)
or
vector<string> listInputs(string deviceName)
There’s still one thing that it’s very well suited for: IOCCC
Leave a Reply