Hungarian notation in C# [duplicate]

Answer 1

One downside of Hungarian notation is that developers frequently change the type of variables during early coding, which requires the name of the variable to also change.

Answer 2

In a language like C# where many of the limitations on variable name length do not exist that were once in languages like C and C++, and where the IDE provides excellent support for determining the type of a variable, Hungarian notation is redundant.

Code should be self-explanatory so names like m_szName can be replaced by this.name. And m_lblName can be nameLabel, etc. The important thing is to be consistent and to create code that is easy to read and maintain - this is the goal of any naming convention so you should always decide what convention you use based on this. I feel that Hungarian notation is not the most readable or the most maintainable because it can be too terse, requires a certain amount of knowledge on what the prefixes mean, and is not part of the language and therefore, hard to enforce and hard to detect when the name no longer matches the underlying type.

Instead, I like to replace Apps Hungarian (prefixes like m_) by referencing this for members, referencing the class name for static variables, and no prefix for local variables. And instead of System Hungarian (including the type of a variable in the variable name), I prefer to describe what the variable is for such as nameLabel, nameTextBox, count, and databaseReference.

Answer 3

It depends.

Is it significant enough to add the description of the data type in variable/object name in your method/class?

System Hungarian Notation > Apps Hungarian Notation

If you are designing in procedural language (e.g. C) that has many of global variables or/and lower-API that deals with precise data types and sizes (e.g. C's<stdint.h>where 40+ different data type notations are used to describe int), System Hungarian Notation is more helpful.

Note, however, many modern programmers consider adding type information in variable name is abundant as many of modern IDEs have very convenient tools (e.g. Outline of Eclipse, Symbol Navigator of Xcode, Visual AssistX of Visual Studio, etc.). System Hungarian Notation was widely used in the earlier ages in programming (e.g. FORTRAN, C99) when type information was not readily available as a tool of the IDEs.

System Hungarian Notation < Apps Hungarian Notation

If you are working in higher-level class or method (e.g. user-defined driver class/method for your C# application), notating simple data type may not be sufficient enough to describe the variable/object. Therefore, we use Apps Hungarian Notation in this case.

For example, if the purpose of your method is to retrieve executable path and to display an error message if not found, instead of noting that it is a type of string, we note more significant information to describe the variable/object for programmers to better comprehend the purpose of the variable/obejct:

private string mPathExe;
private string msgNotFound;

Answer 4

It's about efficiency. How much time was wasted assigning the wrong value to a variable. Having accurate variable declarations are about gain in efficiency. It's about readability. It about following the existing patterns. If you want creativity, do user interface design, do system architecture. If your programming, it should be designed to make you team members job easier: not yours. A 2% gain in efficiencies is an extra week each year. That's 40 hours gained. Human productivity gains are made by compounding efficiencies.

Answer 5

If you hold the pointer over the variable in VS it will tell you what type of variable it is, so there is no reason to go with these cryptic variable names, esp as people that are coming from other languages may need to maintain the code and it will be an obstacle to easy reading.

Answer 6

You're not the only person, but I'd say it's relatively uncommon. Personally I'm not a fan of Hungarian notation, at least not in the simple sense that just restates the type information which is already present in the declaration. (Fans of "true" Hungarian notation will explain the difference - it's never bothered me that much, but I can see their point. If you use a common prefix for, say, units of length vs units of weight, you won't accidentally assign a length variable with a weight value, even though both may be integers.)

However, for private members you can pretty much do what you want - agree with your team what the naming convention should be. The important point is that if you want your API to fit in with the rest of .NET, don't use Hungarian notation in your public members (including parameters).