Why the world hates Hungarian notation?

[Maximilien]

Using meaningful variable names reduce the need to artificially decorate variable name. And in 2012, intellisense type technology makes it easier to keep tab of what type are the variables you are using. IMO, using notepad to do code-review is counter-productive.

Watched code never compiles.

[Eytukan]

Actually I intentionally put that as Notepad though I would be using an IDE for the code review. Because to me both IDE and notepad would mean the same unless I copy the entire project for the review.

Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.

[Lost User]

Nagy Vilmos wrote:

I personally do not use Hungarian notation anymor

Nagy Vilmos? ;)

Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman

[Steve Maier]

For me, I used to use Hungarian when I was coding in MFC and C++. Now that I have been using .NET I don't use it for a few reasons. The modern IDE can show you the type very easily. People have changed types and then were lazy to rename the variables. Names like these are like specs, they get out of date pretty quickly. Some people on my team use the old m_ or just m to say member variable. One person just uses an _ but at the end of the name, not the beginning. So typically since it is a religious war when it comes to things like this or where he proper place to put the curly braces, we typically just state to follow the coding convention that the person wrote the code in. If you cannot understand it, then I really don't want you on my team anyways. ;) Of course taking home 300 lines of code from your work is actually concidered IP theft where I work unless you have a company laptop and can VPN in. That and then picking notepad to view the code is just not right. At least get Notepad+.

Steve Maier

[TheGreatAndPowerfulOz]

Because most people do it incorrectly. The guy, Simonyi, who invented Hungarian notation meant for the names of variables to carry the kind of thing it is, not its type. So, instead of

int iRowScr, iColScr.
List ilBal;

you'd have

int rwScreen, colScreen;
List Balances;

He never intended for the variable name to carry the underlying type, but rather the name should be informative of what it is.

If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun

[Nelek]

Same answer as NagyV

Regards. -------- M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpfull answers is nice, but saying thanks can be even nicer.

[Dr Walt Fair PE]

And I'd automatically assume it might have hyphens and/or spaces and should be alphanumeric. Hence I agree with the OP's idea. Personally I think all edicts are counter productive. I tend to use Hu notation for a few things in C# mainly because I know my conventions and it makes things easier to remember and find.

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[Nish Nishant]

Walt Fair, Jr. wrote:

And I'd automatically assume it might have hyphens and/or spaces and should be alphanumeric.

It depends on the quality of your fellow devs. Most devs I work with would not have "number" in an identifier if it represents a string.

Regards, Nish

---

My technology blog: voidnish.wordpress.com

[Roger Wright]

In every accounting system I've ever used, your assumption would be wrong. ;P

Will Rogers never met me.

[Nish Nishant]

Roger Wright wrote:

In every accounting system I've ever used, your assumption would be wrong. ;-P

Then perhaps, I'd rename that to accountIdentifier or accountId.

Regards, Nish

---

My technology blog: voidnish.wordpress.com

[Dr Walt Fair PE]

Most of the devs I know would tie it back to the data it represents and accounting systems call it Account Number, even if it might be a string. In fact my own accounting system has "Account Numbers" that include letters to differentiate types of clients. When someone calls and I ask for their Account Number, there's never any confusion.

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[Nish Nishant]

Walt Fair, Jr. wrote:

When someone calls and I ask for their Account Number, there's never any confusion.

In that case, since everyone knows it's a string, why would you want to prefix it with s or str or lpsz?

Regards, Nish

---

My technology blog: voidnish.wordpress.com

[Dr Walt Fair PE]

Because you and the devs you work with didn't know and might need to review the code? :laugh: ;P

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[Nish Nishant]

Walt Fair, Jr. wrote:

Because you and the devs you work with didn't know and might need to review the code? :laugh:;-P

You forget that you are talking to a super programmer here. ;P

Regards, Nish

---

My technology blog: voidnish.wordpress.com

[Dr Walt Fair PE]

:cool:

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[Joe Woodbury]

As pointed out above, hungarian notation was meant to signify the purpose of a type, not it's underlying type. The only notation I use is "p" for pointer, "m" for member data and "h" for handle since they indicate a fundamental difference in how they are used. My biggest problem with Hungarian notation are: 1) The abbreviations frequently makes no sense. 2) If code is ported or variables changed, the notation is often wrong. In the current code I'm working on, it's common to find sz in front of pointers, dw in front of long longs. is "b" a bool, BOOL or int? I just looked at some code with an 'h' prefix, but the original programmer had turned it into a pointer (he argues that it's a pseudo-handle--great, then encapsulate it.) 3) In connection with the above, if a data type becomes an abstract type or is extended, it can cause serious confusion. (I've see way too much code where something like bCanReplace actually holds an enumerated value. (Last year, I ported a bunch of code to Unicode in preparation for a CE port. I removed what Hungarian that I could, but the code is littered with "sz" prefixes, among other things--is the sz an ANSI or Unicode string?) 4) It is often accompanied with short variable names. Once you make variable names longer, the meaning becomes clear and the Hungarian notation becomes redundant (and, going with the above, often misleading.) Any developer that insists on using Hungarian should be forced to write a style guide on their personal notation. (On par with my hatred of Hungarian is excessive typedef'ing. Some it nice, even necessary, but I've seen code where they redefine EVERY type for no reason.)

[Philippe Mori]

1. Hungarian notation does not work well with generics or templates or code refactoring (changing an int for a long for example). 2) With modern editors, you will know the type simply by a mouse over a variable. 3) With properly written code (small functions, single responsibility classes...), it should be easy to understand the code anyway. 4) You should avoid cast and the compiler will show most incompatibilities anyway. And if you use int consistently when it make sense, type information won't be that much useful. 5) After having stop to use that notation for more than 5 years, I can say it is much better that way. By using sensible variable and function names, it is generally relatively easy to figure out what the code does. 6) If you are using primitive data types 90% of the time, then you are probably reinventing the wheel and you classes probably have way too much responsibilities. Either with BCL in .NET or STL (or boost) in C++, you should be able to use a lot of existing stuff. 7) If you want to review code, then you should also print the header.

Philippe Mori

[Rob Grainger]

That also has a pretty negative impact on source code control, resulting in changes across multiple files that would otherwise be unnecessary.

[Rob Grainger]

1. It's pug-ugly. 2. It encodes the data type directly in the variable name, if the variable's type changes, all references must be updated. 3. If you have a 300 line code block with no variable declarations, I suspect you have worse problems than use of Hungarian notation. 4. Most people who claim to use HN actually use the HN exemplified by MS in the 1990's. This is mis-use. Original usage used, for example, "i" for index, not for "integer". The prefix was meant to give the usage, not the data type. 5. Insistence of HN in your coding conventions is likely to scare off talented developers. Nowadays, with long variable names, I (along with most other developers) prefer to give variables descriptive, readable names rather than obscure names relying on "conventions" which change with the code-base.

[Rob Grainger]

If your variable declaration's are over 300 lines away from their usage, you've probably got much worse problems than naming conventions.