New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NL.5: Avoid encoding type information in names - even for C #1236
Comments
Some time ago I summerized my view on Hungarian notation (see below). Maybe it contains some points which are worth to incorporate into the C++ Core Guidelines? Discussion of pros and cons of Hungarian NotationNote: Main parts of the following section are copied from Wikipedia. Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its type or intended use. There are two types of Hungarian notation: System Hungarian notation and Apps Hungarian notation. In Hungarian notation, a variable name starts with a group of lower-case letters which are mnemonics for the type or purpose of that variable, followed by whatever name the programmer has chosen; this last part is sometimes distinguished as the given name. In System Hungarian notation, the prefix encodes the actual data type of the variable. For example:
Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.
The article "Making Wrong Code Look Wrong" by Joel Spolsky gives excellent examples on well used App Hungarian notation. Unfortunately the System Hungarian notation is more common. It is much easier to encode the physical data type than finding a consistent encoding for ones application. People using the System Hungarian notation argue that the encoding helps to see what’s going on in the code and to remember the type. But if you relay on the encoded type information to understand the code it may be bad code at all. There are too many global variables in the code, functions are too long and data hiding and abstraction is missing. Consider to rewrite the code. If you change the type of a variable, e.g. from an int to a long you also have to change the name of the variable on every place it is used. Furthermore the System Hungarian notation breaks abstraction. If you have a well designed Application Programming Interface, the type encoding reveals implementation details where it shouldn’t and therefore makes future changes difficult. The Wikipedia article gives a more objective list about advantages and disadvantages, but in the opinion of the author the Hungarian notation should not be used. Finally we want to mention that Microsoft, known as advocate of the Hungarian notation, now discourages its use:
|
Editors: We agree, "needed" is too strong. This is my text so I'll go rephrase, perhaps "has been used in untyped languages." |
Thanks :-) |
I have the problem that people I point to the C++ Core Guidelines use the above statement to argue that the Hungarian notation is disirable for C.
I think this is not the intent of the author. The section gives good arguments against System Hungarian notation, even for the C programming language. At least since C99 and/or with modern static code analysis tools in place.
Even within the Linux kernel there is no need for Hungarian notation. IMHO System Hungarian notation is out-dated.
Can we please adjust NL.5 in a way that it does not suggest Hungarian notation for C.
The text was updated successfully, but these errors were encountered: