It's just about using the Hungarian variable naming convention appropriately

"...and when bmeJames oBond pulled the ftrigger, the sivillian jumped in the mwater."

This is what programmers are put through when reading or writing code in companies where somebody, some-day, misunderstood what the Hungarian notation was actually meant for and created a company policy of naming variables as such.

• bBusy : boolean
• chInitial : char
• cApples : count of items
• dwLightYears : double word
• fBusy : float (or flag)

Apps Hungarian is the original Hungarian. Not Systems Hungarian. If your programmers are annoyed with this notation, they are not wrong. See what the creator of C++ and the creator of Linux have to say about Hungarian:

Bjarne Stroustrup:

No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming — both of which emphasize selection of operations based on the type and arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.

Linus Torvalds:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.

How it all began

It started when Microsoft's chief architect, Dr.Charles Simonyi started it and it came to be known as "Hungarian" because it made variable names look as if they're non-English and also because Dr.Charles is originally from Hungary.
While Microsoft has a respectful article about him, praising how the introduction of the notation helped programmers write better code faster, the adulation could also just be the result of the influence of a powerful person. Given that in the days of the DOS operating system compilers weren't as programmer-friendly, and not being very careful with datatypes could lead to costly bugs when thousands of lines of code were involved, the Hungarian notation could have really helped programmers of that time.


My take on it: The Rudder Notation enhancement

Today's IDE's just need you to hover over a variable to view its type. But inspite of modern IDE's there are people who still find Hungarian useful. It can be useful when maintaining languages which use dynamic typing (JavaScript, for example).

Moreover, although there are various reasons for not using Hungarian, I just need one reason: Readability. We read left to right. Even in the days of DOS OS'es, variables would have been far more readable if the Hungarian notation were used as such:

variableName_typeInformation

Keep the type information away from the variable name with a distinct underscore and keep it on the right side of the camel-case variable. Of course, now that it looks exactly like English, you won't be able to call it the Hungarian notation anymore.

I named it the "Rudder notation" because the type information projects out of the name, pretty much like the rudder of a boat or plane, while also performing the function of guiding the developer or code-reviewer.

Are the variables more readable now?

• busy_b : boolean
• initial_ch : char
• apples_c : count of items
• lightYears_dw : double word
• busy_f : float (or flag)

Some people want to use Hungarian because they may some-day take printouts of their code. Really? Then you're very likely doing something very wrong somewhere. Others have written long posts on Hungarian; but really...

...what you need to do, is identify which variables could mistakenly introduce bugs in your code, and apply the Rudder notation to them. This identification is very much dependent on what kind of application you are building, and not on the language or the datatype.

Forming a policy for your programmers to follow by doing a monkey-see-monkey-do of somebody else's Hungarian policy would not just be unwise, it would create a culture where team leads force ideas onto the team without understanding the idea, and cause disgruntlement within teams who don't see the point or value that the policy adds to their work. Instead, educate them to recognize potential problem areas and create a culture where they share this info with each other. Creates a better sense of ownership.

-----------------------------------------------------------------------------------------

Update: Apparently I'm not the first person to suggest the underscore for Hungarian (but I'm the one who christened it the "Rudder notation"). c2.com pointed me to 'experts' who have already encouraged it: http://www.intentsoft.com/hungarian_notat/