Skip to content
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

Closed
franzhollerer opened this issue Jun 21, 2018 · 3 comments
Closed

NL.5: Avoid encoding type information in names - even for C #1236

franzhollerer opened this issue Jun 21, 2018 · 3 comments
Assignees

Comments

@franzhollerer
Copy link
Contributor

Requiring techniques like Hungarian notation to encode a type in a name is needed in C, but is generally unnecessary and actively harmful in a strongly statically-typed language like C++, because the annotations get out of date (the warts are just like comments and rot just like them) and they interfere with good use of the language (use the same name and overload resolution instead).

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.

@franzhollerer
Copy link
Contributor Author

franzhollerer commented Jun 21, 2018

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 Notation

Note: 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:

- lAccountNum : variable is a long integer (l)dsf
- arru8NumberList : variable is an array of unsigned 8-bit integers (“arru8”)

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.

- rwPosition : variable represents a row (rw), e.g. in an spreadsheet application>
- usName : variable represents an unsafe string (us), which needs to be 'sanitized' before it is used

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:

X DO NOT use Hungarian notation.

@hsutter hsutter self-assigned this Jul 9, 2018
@hsutter
Copy link
Contributor

hsutter commented Jul 9, 2018

Editors: We agree, "needed" is too strong. This is my text so I'll go rephrase, perhaps "has been used in untyped languages."

@franzhollerer
Copy link
Contributor Author

Thanks :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants