Should I use hungarian apps notation in C#?

Question

I know this question has been asked around a bit, and by the looks of it, there isn't a clear yes or no answer to this question, but still, I'm a little confused about something.

Usually when I program, I follow a few rules about prefixes:

• m_ in front of members
• p_ in front of properties
• s_ in front of static
• a_ in front of parameters
• l_ in front of local variables

I got a new job right now, and I noticed that prefixes are not used in code. I asked why, and they replied that IDEs do all the work of keeping track of what's a member variable and what's a local variable. Now I'm thinking, that may be so, but isn't it easier to use prefixes anyway?

I mean, if I for example have a member, a static, and a local variable named "robot", would it not be a pain in the ass to reference it when writing a method? This is perhaps an unrealistic example, but I like to have a good rule-set in my head that I can apply consistently, even for unrealistic conditions.

Does this example justify using Hungarian notation?

I think I'll make a pros/cons list and edit it as I learn more about it.

Argument against hungarian:

Class.Robot or Robot

this.robot

robot

No need for Hungarian.

Counter:

There is still an inconsistency, Robot could mean different things in different methods. To stay consistent you should prefix Class or this (or nothing) before each Robot variable.

On top of that, lets say you want to access the static variable Strawberry, how do you know a member variable named Strawberry isn't defined? Maybe it's defined in another file that you can't see, so you might get unexpected results. Now you might say that this is visible via the IDE but I make the argument that using a prefix is superior because you see what you're referencing, while you might miss what the IDE is telling you. You could also use this/Classname prefixes of course but that kind of defeats the purpose of not using a Hungarian notation.

Argument against hungarian:

A violation of this rule occurs when Hungarian notation is used in the naming of fields and variables. The use of Hungarian notation has become widespread in C++ code, but the trend in C# is to use longer, more descriptive names for variables, which are not based on the type of the variable but which instead describe what the variable is used for.

Counter:

The prefixes I mentioned are not based on the type of the variable, the prefixes indeed specify what the variable is used for.

Argument against hungarian:

modern code editors such as Visual Studio make it easy to identify type information for a variable or field, typically by hovering the mouse cursor over the variable name. This reduces the need for Hungarian notation.

Counter:

While this is true, I myself almost never hover with my mouse above a variable name unless an error has occurred. In contrast, with Hungarian notation, you immediately see where your variable is located in the class.

Remark:

Doesn't Microsoft recommend using Hungarian notation for file names? I read that it is a convention to prefix interface files with an I, this is a form of Hungarian notation. While this doesn't directly relate to my question above, it does raise the point that Hungarian notation is sometimes recommended.

Answer 1

The answer is no, as everyone wrote here already.

First of all: You're not actually using the hungarian notation - or a known variant of it - as you state in the question yourself.

So let's start with the problem that you use a naming convention that is one of your own making and not widely used. This leads to immediate problems as soon as you are exposing your code to the real world - like your new coworkers. You're just inventing a private third (nth?) variant of this prefix notation, with all the problems that forcing something uncommon on other people includes.

Now - is it a change for the better? Are you right, and the other people should adapt to gain from these set of rules?

The consensus here seems to be 'No' and I'm fiercely on that side. Ignoring the standard arguments about the hungarion notation (I dismiss them as 'not entirely relevant'):

• Don't reuse names to mean lots of things. The one exception that still seems to be common is to have a constructor taking an argument with the same name as a field:

  public Foo(string robot) { this.robot = robot; }

• If you have trouble managing the sheer number of names in your code, chances are you have too many of those in one place / in scope. You're trying to solve a code smell with a (smelly, according to the consensus here so far) workaround

• To reiterate it once: You come to a team of people that don't use your convention (and how could they - it seems it's of your own making..) so you have to adjust to the team. You can argue about personal readability and are free to ask your coworkers to reconsider, but if they disagree with that style: Don't fight it. You're just making yourself miserable if you insist on being right and them being wrong. Don't let this drain your productivity.

Answer 2

No, do not use Hungarian Notation. First, it's so 1990s. Secondly, you may be assaulted by your co-workers... ;-)

Your robot example:

Class.Robot or Robot

this.robot

robot

No need for Hungarian.

Answer 3

No, don't do it. It makes the code harder to read. If you wrote English with every verb with a v_ in front and every noun with n_ that would make the sentence harder to read while adding information that is not useful most of the time.

If your classes are well designed with few responsibilities and short methods it shouldn't be too difficult to figure out what each variable means from the name and the context in which it is used. When it's not obvious and you need to know, it's easy to find out: you can just hover the mouse over the variable name, or press "Go To Definition".

StyleCop has a rule that warns when you use Hungarian notation. The rule description has a little explanation about why that rule exists:

---

• TypeName FieldNamesMustNotUseHungarianNotation
• CheckId SA1305
• Category Naming Rules

Cause

The name of a field or variable in C# uses Hungarian notation.

Rule Description

A violation of this rule occurs when Hungarian notation is used in the naming of fields and variables. The use of Hungarian notation has become widespread in C++ code, but the trend in C# is to use longer, more descriptive names for variables, which are not based on the type of the variable but which instead describe what the variable is used for.

In addition, modern code editors such as Visual Studio make it easy to identify type information for a variable or field, typically by hovering the mouse cursor over the variable name. This reduces the need for Hungarian notation.

Answer 4

I for myself have some convention that I follow. It's true that modern IDEs take away a lot of things like this but still I think a little hungarian :). I'm using:

robot_ for attributes (ms recommends to use this.robot but like this I can't forget the this)
camelCase for local variables and private/protected/internal methods
PascalCase for public properties or methods

And that is it :). I think the code looks very weird with all these m_, a_, ... stuff I find it very difficult to read. Hovering over the code in VS gives you hints sure, but I see some additional benefit in using some kind of convention.

I mean even ms uses some kind of hungarian notation in postfixing all async functions with Async or prefixing all interfaces with I

Answer 5

but I like to have a good rule-set in my head that I can apply consistently

Even better than a rule-set in your head, is a rule-set in your IDE/build system:, so you should check out StyleCop

StyleCop will let you configure your coding guidelines how you like, but by default offers a popular alternative to the apps hungarian notation you describe:

• fields: this.myField
• properties: this.MyProperty
• methods: this.MyMethod()
• statics: MyClass.MyStaticMethod()
• etc.

You'll find endless discussion on this aspect of coding style both on stackoverflow and elsewhere, so I expect this question will be closed as a duplicate....