m_

We all know that Hungarian notation is bad. That has been debated a thousand times and closed upon. It has been proven that having type information as the variable name can lead to trouble. Some nice examples are here and here.

However, though most developers agree with the issues with type information in the variable name, there is some lack of clarity on the other aspects of variable naming. Like the m_ prefix. Many developers believe that it's ok to use m_ for non-public variables, especially because it can be easy to get confused between local and instance variables. Some even prefer just an underscore prefix.

The .NET Fx guidelines and MS internal coding guidelines clearly calls out against it and so does tools like FxCop and StyleCop. The reason is simple; it looks ugly and has other repercussions. For example if one uses m_ for instance variables, then he might want to call out static variables with s_ and global variables (yea C# is exempt) with g_. So one falls into the same trap while changing a static to an instance variable or vice-versa.

Moreover, these prefixes are simply not needed. The guidelines suggested way of using a this. prefix works much better, as you clearly use the this pointer indicating that the reference is to an instance variable. Topics like these turn into religious war during code-reviews or reviews of team wide coding guidelines. I personally believe that things like prefixes has no place in todays world of coding…

Comments

• Anonymous
  November 27, 2006
  Hungarian notation is only bad when it's done wrong.Unfortunately, despite being invented at Microsoft, Microsoft systems division were the ones who got it wrong (by not reading carefully enough and misunderstanding the word "type", despite Simonyi making things pretty clear in his papers & examples) and taught everyone else how to do it wrong.See also:http://www.joelonsoftware.com/articles/Wrong.htmlhttp://en.wikipedia.org/wiki/Hungarian_notationOf course, MS can't admit they got it wrong for 20 years and tell people how it should be used now, can they? That would make them look stupid. (!) No, they just say not to use it at all as "Code legibility should be a primary goal" instead.
• Anonymous
  November 27, 2006
  In fact, MS do recommend Hungarian, as prefixing interfaces with "I" is a really good example of Apps Hungarian. It's naming something based on what "type" of thing it is; not the underlying system type used to represent it, but the actual semantic type of thing being named.They just don't call it Hungarian, even though it is.
• Anonymous
  November 27, 2006
  The speedy popup listbox of variables in VS can get you in trouble if you have two names that vary only in captialization.  After mistakenly putting in the wrong variable name time after time I went back to the m_ convention.  It sure saves a lot of time fixing up errors.
• Anonymous
  November 27, 2006
  Thats why Fx Design Guideline suggests to use this. prefix for all instance variable. With this the issue of casing goes away as you'd definitely not have two instance variable that differs by case only.
• Anonymous
  November 27, 2006
  But the compiler does not enforce the use of this. If that was the case we could stop using m_, but it is just to easy to forget using this. FxCop does not help us either. And StyleCop seems to be an internal MS-tool.So we have an FxCop rule that specifies that you must use m_ (and s_ for statics). This way we exclude a whole lot of errors during coding instead of during testing.
• Anonymous
  November 28, 2006
  I think there's a good reason for using a member variable prefix (I use '_'): intellisense.  Using "this." works great in your own library classes, but in windows forms classes, typing "this." brings up a monster list of inherited items, which makes trying to lookup a private variable rather difficult.
• Anonymous
  November 29, 2006
  Changing a variable from being an instance variable to being global variable or a static variable is a major design change in the class and structure of the program.So, requiring the programmer that makes this choice/decision to go and update all the references is something don’t see a problem, in the extreme case it allows him to check the impact of this change in the rest of the code. On the occasions that I’m about to make a decision like this I comment the variable and compile the program just to see all the dependencies and be sure I’m not making implicit mistakes.And regarding "the main don't do it argument" against the Hungarian notation, I find it strange that people say that when all major code editors have good capabilities regarding find and replace, or people doing the Hungarian notation all use notepad?!I use a simplified form of Hungarian notation, because if find it helpful when coding to know if I’m dealing with a class, pointer, integer, … variable.
• Anonymous
  November 30, 2006
  The .NET Fx guidelines and...clearly calls out against it and so does tools like FxCopThey do no such thing. The Design Guidelines only talk about externally visible members and types, and FxCop does not fire on the naming of private members.
• Anonymous
  December 01, 2006
  The comment has been removed
• Anonymous
  January 17, 2008
  Can anyone help me in finding some good study material for StyleCop Thanks and Regards Swapnil Saxena