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 (10)

  1. Adam says:

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

    http://en.wikipedia.org/wiki/Hungarian_notation

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

  2. Adam says:

    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.

  3. Doug says:

    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.

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

  5. TValoy says:

    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.

  6. Peter says:

    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.

  7. Cláudio says:

    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.

  8. The .NET Fx guidelines and…clearly calls out against it and so does tools like FxCop

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

  9. MZ says:

    More baggage from C++ – "this." is a fistful of characters to type for every member variable access.  In VB.net, you get the far shorter "me." instead of "this.", and can use "with" in a pinch.  In Ruby, it’s simply the super-short @ prefix.

    The whole reason I use the hungarian approach of a prefix is to let me overload names – this._target is the private representation of this.Target, target is a local variable or argument.  I would love to take the MS-recommended "this" approach, but that would create an "option-explicit-off" style minefield if I misdeclared or forgot to declare a local.  Then I could accidentally overwrite a private member when I was just trying to fiddle with a local.

    Perhaps it would be better if C# used the Ruby/Python approach of keeping the members in a seperate namespace – Ruby accesses the members with the @ operator, and Python passes in "self" implicitly as the first parameter to every method (which is a bit of a headache since it means you have to include "self" in every method function signature).  

    I appreciate the MS approach, but I’m going to stick to my method of "private fields/properties are lowercase with _ prefix" for safety.  Plus, the 2005 "refactor-rename" system makes renaming variables easy, so if I need to update a name it’s a simple operation.  

    Plus, the underscore approach is practically necessary in VB.Net where you can’t overload names using casing.

  10. Swapnil Saxena says:

    Can anyone help me in finding some good study material for StyleCop

    Thanks and Regards

    Swapnil Saxena