Hungarian notation in C# [duplicate]

Answer 1

You're certainly not the only person, but I do hope you're part of a declining trend :)

The problem with Hungarian notation is that it's trying to implement a type system via naming conventions. This is extremely problematic because it's a type system with only human verification. Every human on the project has to agree to the same set of standards, do rigorous code reviews and ensure that all new types are assigned the appropriate and correct prefix. In short, it's impossible to guarantee consistency with a large enough code base. At the point there is no consistency why are you doing it?

Furthermore tools don't support Hungarian notation. That might seem like a stupid comment on the surface but consider refactoring for instance. Each refactoring in a Hungarian naming convention system must be accompanied with a mass rename to ensure that prefixes are maintained. Mass renames are susceptible to all sorts of subtle bugs.

Instead of using names to implement a type system, just rely on the type system. It has automatic verification and tool support. Newer IDE's make it much easier to discover a variable's type (intellisense, hover tips, etc ...) and really remove the original desire for Hungarian Notation.

Answer 2

At some point, you're likely to have a property

public string ExecutablePath { ... }

(not that you should try to avoid abbreviations like "Exe" too). That being the case, your question might then be moot much of the time as you can use C# 3.0's auto-properties

public string ExecutablePath { get; set; }

you now no longer have to come up with a name for the backing store variable. No name, no question/debate about naming conventions.

Obviously, auto-implemented properties aren't always appropriate.

Answer 3

unless you are using a text editor rather than the VS IDE there is little value to hungarian notation and it impeeds rather than improves readability

Answer 4

The real value in Hungarian notation dates back to C programming and the weakly typed nature of pointers. Basically, back in the day the easiest way to keep track of the type was to use Hungarian.

In languages like C# the type system tells you all you need to know, and the IDE presents this to you in a very user friendly way so there is simply no need to use Hungarian.

As for good reason to not use it, well there are quite a few. FIrstly, in C# and for that matter C++ and many other langause you often create your own types, so what would be the Hungarian for a "MyAccountObject" type? Even if you can decide on sensible Hungarian notations it still makes the actual variable name slightly harder to read because you have to skip past the "LPZCSTR" (or whatever) at the start. More important is the maintainance cost though, what if you start of with a List and change to another type of collection (something I seem to do a lot at the moment)? You then need to rename all your variables that use that type, all for no real benefit. If you had just used a decent name to begin with you wouldn't have to worry about this.

In your example, what if you created or used some more meaningful type for holding a path (e.g. Path), you then need to change your m_strExePath to m_pathExePath, which is a pain and in this case not actually very helpful.

Answer 5

Most hungarian notation describes what the variable is (a pointer, or a pointer to a pointer, or the contents of a pointer etc. etc.), and what the thing that it points to is (string etc).

I've found very little use for pointers in C#, especially when there's no unmanaged/pinvoke calls. Also, there's no option to use void* so there's no need for hungarian to describe it.

The only left-over from Hungarian that I (and most others in C# land) use, is to preceed private fields with _, as in _customers;

Answer 6

The only two areas where I currently see any form of Hungarian notation are:

• Class member variables, with a leading underscore (e.g. _someVar)
• WinForms and WebForms control names (btn for Button, lbl for Label etc)

The leading underscore on member variables seems like it is here to stay with us for a while longer, but I expect to see the popularity of Hungarian on control names to wane.