3

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.

NomenNescio
  • 2,899
  • 8
  • 44
  • 82
  • possible duplicate of [Hungarian notation in C#](http://stackoverflow.com/questions/768255/hungarian-notation-in-c-sharp) – BrokenGlass Nov 30 '11 at 23:33
  • I would be atypical for C#. In any case, I recommend following whatever style is used within your group, as stylistic consistency is generally more valuable than the value added by any particular style. – Dan Bryant Nov 30 '11 at 23:35
  • Also see http://stackoverflow.com/questions/111933/why-shouldnt-i-use-hungarian-notation –  Nov 30 '11 at 23:39
  • 1
    You ask a question, but seem hard to convince (you dismiss all arguments so far). Are you sure that you want an answer that is different from "Go on and use it"? – Benjamin Podszun Dec 01 '11 at 14:06
  • [3 years later.] I'll go popular opinion and say that judicious use of Hungarian notation still improves code readability. From the list of variable scope prefixes listed by the O.P., I'm still using `m_` for private member variables and `s_` for private static variables. Recently, I did a [write-up](http://reconvolution.blogspot.com/2014/07/what-happened-to-hungarian-notation.html) about why Hungarian is not used as widely as it used to be used, and where Hungarian could still be beneficial. – Nick Alexeev Dec 26 '14 at 22:15

5 Answers5

10

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.

Mark Byers
  • 811,555
  • 193
  • 1,581
  • 1,452
  • 1
    There are two types of Hungarian notation: Systems Hungarian and Apps Hungarian. Which one are you telling the world not to use? But before retorting to my question and commenting, take a look at this [interesting read](http://www.joelonsoftware.com/articles/Wrong.html). – sampathsris Jul 03 '14 at 11:24
  • Hungarian is simple to read for developers, harder to read for non developers. Keep the abbrevations down and use full object name as prefix for object values then the code will be much easier for developers to read – Per Ghosh Apr 02 '22 at 00:54
4

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.

Jakub Konecki
  • 45,581
  • 7
  • 87
  • 126
  • 1
    But if you do that, then, Robot might mean a different thing in two different methods, isn't that a point of confustion? and if you always prefix with Class or this, then you should logically prefix each static and member variable in your methods to stay consistent, doesn't that kinda defeat the purpose of not using prefixes? – NomenNescio Nov 30 '11 at 23:37
  • 5
    @NomenNescio: If "Robot" means two different things in two places then you have bigger problems with your code than the naming conventions. That's the problem you should be *fixing* by *changing the logic so that you don't have the same word meaning two different things in two places.* Putting a bunch of crazy prefixes on the words doesn't make it easier to understand *how their meanings are different*. – Eric Lippert Dec 01 '11 at 05:10
  • @EricLippert: By that logic, I should never give the arguments the same name as a member variable (a fairly common practice), because then I have a variable meaning two different things in two different places. To avoid this, I'll probably have to use some other prefix that shows what the variable is used for. For example Robot for the member variable and NewRobot for a method parameter. But you can run into problems with this because sometimes a variable's meaning is too complex, and would end up too long to be expressed in the name of a Parameter. – NomenNescio Dec 01 '11 at 08:30
  • @EricLippert: Would it not be more logical to put the "meaning" of the variable in the documentation rather than the name of the variable? Because then you avoid potentially complex variable names. The only disadvantage I can think of Hungarian notation with the right documentation is that IDEs won't play as nice with them as they would otherwise. but this is I think a peripheral issue because that doesn't apply to programming directly. – NomenNescio Dec 01 '11 at 08:35
  • 2
    @NomenNescio - no developer read documentation for each method they are about to modify/debug. The name of the argument to the method and the property to which it is assigned can be the same, as they both represent the same 'thing'. Consider constructor `Rectangle(int width, int height) { this.Width = width; this.Height = height; }` Both 'widths' and 'heights' have the same meaning of a dimension. There is no need to use different names. – Jakub Konecki Dec 01 '11 at 09:27
  • @JakubKonecki Yes, it is true that not many people read the documentation, but I think this is more of a IDE issue rather than a programming issue. Java in Eclipse does this quite nicely as you can read the methods documentation by clicking on the method, but alas, I digress. About "this", how do you decide when to use "this" and when not to use "this"? Do you use this every time when referencing a member variable? this is certainly more verbose than m_, whether it is more readable is a matter of opinion. – NomenNescio Dec 01 '11 at 10:09
  • @JakubKonecki One advantage "this" does offer tough is that when you use it, you "know" you are referencing a member variable, while if you use m_, you assume you are referencing a member variable. On the other hand, Hungarian notation "limits" the amount of decisions/choices you have to make to write your code. Certaily I don't have to think about when to use "this" and I also have a simpler time coming up with names for my variables. – NomenNescio Dec 01 '11 at 10:14
3

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.

Benjamin Podszun
  • 9,679
  • 3
  • 34
  • 45
2

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....

Ergwun
  • 12,579
  • 7
  • 56
  • 83
1

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

mfeineis
  • 2,607
  • 19
  • 22