C# coding standards for private member variables?


I’ve read numerous documents and books and seen various references on how to refer to private member variables in a class. I have been inconsistent myself depending on what I’m doing and I’m wondering what some others out there use or recommend.


Here are the ways I know of:



  • _memberVariable
  • m_MemberVariable
  • m_memberVariable
  • this.memberVariable

For instance, Juval Lowy recommends m_MemberVariable. However, everything else I’ve read says “Hungarian notation, don’t go there.”


Here is my take. I like using this. because when I type the period Intellisense kicks in any my lazy brain doesn’t have to remember all the member variables in my class (I just discovered control-spacebar though). However, writing this. everywhere clutters up the code. I also don’t like the underscore style cause it can sometimes look quite funny:



  • this._memberVariable
  • (string)_memberVariable etc.

I like just using memberVariable and only using this in the constructor or any method where I might be taking a parameter named memberVariable. Make sense?


For me this is the only area of the coding standards that are completely inconsistent depending on what I read and who is writing the code. Further I’ve noticed that within the .NET framework base classes there is usage of both the Hungarian style and the underscore style.

Comments (11)

  1. JosephCooney says:

    At least in C# the last option is a viable one – you can call the private member ‘memberVariable’ and create a PascalCased accessor ‘MemberVariable’. In VB.NET you pretty much have to use some sort of prefix (or a different name alltogether), since it is not case-sensitive.

    I’m a fan of either the first or last option, but even the first one smacks a bit too much of hungarian to me. I do agree it is a bit of a grey area.

  2. Jason Salas says:

    HI Omar,

    I can’t personally speak for the architectural benefits (if any), but I’ve read several books, and some denounce the use of "_someVar", implying that such might be bad programming practice, while others highly recommend it, for readability.

    I personally side with the latter.

  3. George Chernyha says:

    Omar,

    Very interesting. Naming conventions seem to be a hot blog topic the last few days. The timing couldn’t have been better for me as I am about to embark on putting together some C# coding standards for my employer. I’m looking forward to seeing what other people have to say.

    I’ll have to say that I’m not a fan of decorating the names of classes, interfaces, variables, etc. in the interest of readability. Scope shouldn’t really matter. Oh, and forget anything that includes the cursed underscore; that’s a really finger breaker.

    I believe that a consitantly applied casing convetion, i.e. camel case for member/private variables, Pascal case for everything else fills the readability requirement. Beyond that, class names should be nouns, interfaces adjectives or adverbs.

  4. Steve Maine says:

    I use underscore notation only for private member variables that back properties of the same name. So the private _foo variable backs the publicly visible Foo property. The underscore is intentionally painful; I’m more apt to refer to the property through its accessor even within the same class. That way, if I add functionality to the accessor later, I’m covered in all cases.

    I try to avoid private member variables that don’t back properties as a general matter of style. In the cases where a private member variable makes sense, I usually camelCase it and prefix it with "this." — both for Intellisense and to prevent me from accidentally thinking it’s a function parameter instead of local state.

    Regardless of what style you pick, I think internal consistancy is the most important thing.

  5. Scott says:

    Agreed, as someone who has often had to inherit legacy code I don’t really care WHAT standard someone follows as long as they follow it. My personal style, since I’m usually the lone developer on a project, is to name my vars using hungarian notation when I’m dealing with a weakly typed language (e.g. VBScript or Javascript) especially if I’m going to be working on them in an environment that doesn’t support intellisense (e.g. writing an ActiveX transformation or task in a DTS package). Private member vars I prefix with _. Whenever I’m setting/manipulating them I use the "this" keyword. I think it’s paranoia about making sure I’m referring to an instance var rather than referencing any kind of a global var.

    PS if you think (string)_varName looks funny, avoid C++ where the double underscore __ is (was) a standard.

  6. I’m a VB.NET programmer so feel free to ignore me… I find m_MemberVariable or m_memberVariable the best approach as all of the private variables sort together, there is no confict with local variable names, method or property names, and it serves as a reminder that they are private variables.

  7. David Cumps says:

    is use private memberVar as a var, create a property of it, and always do this.Property

    (in C#)