Do people use the Hungarian Naming Conventions in

Question

Is it worth learning the convention or is it a bane to readability and maintainability?

Answer 1

I don't use a very strict sense of hungarian notation, but I do find myself using it sparing for some common custom objects to help identify them, and also I tend to prefix gui control objects with the type of control that they are. For example, labelFirstName, textFirstName, and buttonSubmit.

Answer 2

Isn't scope more important than type these days, e.g.

• l for local
• a for argument
• m for member
• g for global
• etc

With modern techniques of refactoring old code, search and replace of a symbol because you changed its type is tedious, the compiler will catch type changes, but often will not catch incorrect use of scope, sensible naming conventions help here.

Answer 3

Sorry to follow up with a question, but does prefixing interfaces with "I" qualify as hungarian notation? If that is the case, then yes, a lot of people are using it in the real world. If not, ignore this.

Answer 4

I still use Hungarian Notation when it comes to UI elements, where several UI elements are related to a particular object/value, e.g.,

lblFirstName for the label object, txtFirstName for the text box. I definitely can't name them both "FirstName" even if that is the concern/responsibility of both objects.

How do others approach naming UI elements?

Answer 5

I've been working for IBM for the past 6 months and I haven't seen it anywhere (thank god because I hate it.) I see either camelCase or c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Answer 6

What's wrong is mixing standards.

What's right is making sure that everyone does the same thing.

int Box = iBottom * nVerticleSide