Hungarian Notation vs others

[sunil.thaha]

Hi Guys...

I know this is more of a controversial topic. But, could you please provide some pros and cons of using Hungarian notation in C++? I find that Qt doesnot use this cryptic notation and that makes it more legible that MFC (which uses Hungarian ). This is what one of the articles in the Qt Quarterlies talk about. You will even notice that this notation is not used in some of the most well written frameworks like that of Java.

When I speak against the usage of this notation in a project, I get a hell lot of goodies about this notation. Some people go to the extend that if a global variable starts with g_, then make local varaibles l_, arguments to functions f_, class data-members m_. Has anyone faced/know-of and cons ...
Yup I am more interested in the cons though ;)

Can you share your views please ...

[wysota]

AFAIK Hungarian notation was created in Microsoft and I think they are the only ones really using it... Them and of course the programmers brainwashed by them (no offense).

I personally hate that notation. Everything is fine as long as you read code you created, but it gets worse if you need to read code written by someone else that is related to types you don't know (I don't even know what lpStr means.... long pointer? local pointer?). Hungarian notation was created for C-like languages and doesn't make much sense (of course in my opinion) for object oriented languages (you shouldn't really care about the type of a variable).

Qt uses the camel notation for naming classes and name()/setName() convention for naming getters and setters, but it doesn't enforce any convention in naming variables. You can even use it together with HN if you want to. To distinguish global and local variables some languages use the object prefix (like "this" for C++ or "self" for Python). It makes code longer but improves readability. I personally prefer to read "self.value" than "luiValue" (local unsigned int?). Short variable names are fine for interpreted languages (less code to parse) but for compiled ones variables should be as descriptive as can be (imagine a backtrace full of luis, lps and other funny names - try to find anything there). I'm probably not the best advocate of the latter statement as I tend to sometimes name my variables "i", "v" or "tmp3" but believe me, it's much better than it was few years ago. Maybe in another five years I won't be using "tmp" variables anymore :)

[jacek]

could you please provide some pros and cons of using Hungarian notation in C++?
Hungarian notation was invented, because C doesn't have strict type checking. The key concept was to encode the type of a variable in its name to make it harder to overlook the type. You simply don't need this in C++ --- even IDEs know the types of your variables. ;)

Although prefixes (or suffixes) for member variables are quite usefull. I've also seen one of Java libraries that used p prefix for method parameters. But this is really a matter of style, while hungarian notation helped to preserve hair on C programmers' heads.

[sunil.thaha]

I stumbled upon these comments on Hungarian notation by Bjarne, yesterday

link: http://www.research.att.com/~bs/bs_faq2.html#Hungarian



No I don't recommend "Hungarian". I regard "Hungarian" (embedding an abbreviated version of a type in a variable name) 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 an 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. To various extent, I have similar problems with every scheme that embeds information about language-technical details (e.g., scope, storage class, syntactic category) into names. I agree that in some cases, building type hints into variable names can be helpful, but in general, and especially as software evolves, this becomes a maintenance hazard and a serious detriment to good code. Avoid it as the plague. So, I don't like naming a variable after its type; what do I like and recommend? Name a variable (function, type, whatever) based on what it is or does. Choose meaningful name; that is, choose names that will help people understand your program. Even you will have problems understanding what your program is supposed to do if you litter it with variables with easy-to-type names like x1, x2, s3, and p7. Abbreviations and acronyms can confuse people, so use them sparingly. Acronyms should be used sparingly. Consider, mtbf, TLA, myw, RTFM, and NBV. They are obvious, but wait a few months and even I will have forgotten at least one.
Short names, such as x and i, are meaningful when used conventionally; that is, x should be a local variable or a parameter and i should be a loop index.
Don't use overly long names; they are hard to type, make lines so long that they don't fit on a screen, and are hard to read quickly. These are probably ok:
partial_sum element_count staple_partition
These are probably too long: the_number_of_elements remaining_free_slots_in_symbol_table
I prefer to use underscores to separate words in an identifier (e.g, element_count) rather than alternatives, such as elementCount and ElementCount. Never use names with all capital letter (e.g., BEGIN_TRANSACTION) because that's conventionally reserved for macros. Even if you don't use macros, someone might have littered your header files with them. Use an initial capital letter for types (e.g., Square and Graph). The C++ language and standard library don't use capital letters, so it's int rather than Int and string rather than String. That way, you can recognize the standard types. Avoid names that are easy to mistype, misread, or confuse. For example
name names nameS
foo f00
fl f1 fI fi
The characters 0, o, O, 1, l, and I are particularly prone to cause trouble. Often, your choice of naming conventions is limited by local style rules. Remember that a maintaining a consistent style is often more important than doing every little detail in the way you think best.

[danadam]

Hungarian notation was invented, because C doesn't have strict type checking. The key concept was to encode the type of a variable in its name to make it harder to overlook the type. You simply don't need this in C++ --- even IDEs know the types of your variables. ;)

There is an interesting article/blog post (http://www.joelonsoftware.com/articles/Wrong.html) on Hungarian notation (how it was at the beginning and how it is now).

[jacek]

There is an interesting article/blog post (http://www.joelonsoftware.com/articles/Wrong.html) on Hungarian notation (how it was at the beginning and how it is now).
Indeed, very interesting. I fully agree with the author that the "Systems" variant is completely unnecessary.

[elcuco]

And still this has good way and bad was to (ab)use it. When coding in HTML/JavaScript/CSS, all my CSS classes start with "cls".

Even when programing in C++/Qt, all my GUIs use this notation. For example btnHelp (help button), cbAutoBracket (check box auto brackets) etc. The rationale is that I can start typing "btn" and I see the list of all buttons on my GUI - less to filter - less to write.

...and even Qt uses it to some sort: on_actionOpenFile_triggered() for example.

There is always good and bad ways to use technology. "This was invented by some Hungarian dud for MS" is not a good excuse for me, I like this and I use it.

[wysota]

I read the article as well and according to me it simply doesn't show the full picture. The author bases his case study on web content and languages that handle web content are mostly very high lever without strict type checking and as Jacek mentioned in his earlier post in such situations it might make sense to use the notation to distinguish between different types (or maybe "flavours") or variables. But for languages with strict type or scope checking it doesn't make much sense and if something is forbidden, it should be blended into the syntax or semantics of a given language (like the "const" modifier in C++) or framework (like the warnings present in Qt) and not by suggesting an additional layer of "type checking" performed by the end user (programmer) in the form of variable naming scheme effectively doubling what the compiler does anyway. It resembles a situation that always made me grin when a shop assistant would use a calculator to sum up prices of products and then would doublecheck the result by doing the addition again manually on paper.

[wysota]

...and even Qt uses it to some sort: on_actionOpenFile_triggered() for example.

I disagree. It's something completely different. It's just a way to have an easily parsable string containing both the object and the method. I'd say it more resembles the "descriptive" approach.

And still I don't fully agree with a statement that a hungarian-like naming convention enables one to easily find variables of a given type. It's fine as long as you are the only one reading the code, but I doubt anyone who doesn't know Qt would guess that qsfpmSomething stands for QSortFilterProxyModel and without knowing what qsfpm means the convention is useless and error prone. However I accept it as a fully qualified variable naming convention. As they say - "Whatever makes you happy...".

[elcuco]

I disagree. It's something completely different. It's just a way to have an easily parsable string containing both the object and the method. I'd say it more resembles the "descriptive" approach.

And still I don't fully agree with a statement that a hungarian-like naming convention enables one to easily find variables of a given type. It's fine as long as you are the only one reading the code, but I doubt anyone who doesn't know Qt would guess that qsfpmSomething stands for QSortFilterProxyModel and without knowing what qsfpm means the convention is useless and error prone. However I accept it as a fully qualified variable naming convention. As they say - "Whatever makes you happy...".

on_actionOpenFile_triggered()

[wysota]

You mean the "action" part? It's strictly coincidential. Could be "on_OpenTheFuBEEEPWindow_clicked()" as well... As far as I understand HN, it is based around abreviations and we don't have such things here. Even the object is called "actionOpenFile" and not "aOpenFile". According to me that makes a huge difference.

[sunil.thaha]

And I believe that HN, will fails when templates come to picture.

How will a QMap< QString, QMap<QString, QList<MyCustomClass> > > be called :)...