Using underscore to prefix private member fields

Joe Stagner blogged today about some basic coding guidelines one of which was to avoid using any sort of prefix for member variables (including the underscore). I personally prefer to use the underscore prefix on private member fields and mainly so they would be easily identifiable from local variables. But Joe’s guidelines suggested a workaround recommending that we use this to indicate a member variable.

private int _age;

void Foo()
{
    int age;
    //...
    if(age > _age) // <-- My way
    {
        //...
    }
}
private int age;

void Foo()
{
    int age;
    //...
    if(age > this.age) // <-- Joe's recommendation
    {
        //...
    }
}

While I did think that was a fair approach, I am still not convinced it’s fully alright since the onus is on the coder to remember to do this – there’s nothing stopping him from forgetting to prefix this for member fields. So for the time being I am going to continue using underscore for private members.

17 thoughts on “Using underscore to prefix private member fields

  1. But properties would always use Pascal casing. So they would never clash with a private field, would they?

    In my example, if there was a property it would be Age

  2. Yes, but Pascal case has no sense in VB.NET therefore in order to mantain compatibility rules I prefer using “m_” as prefix of private members.

  3. I use the underscore approach too for the exact same reason. I tried doing the “this.” approach, but too many opportunities for coder errors if you ask me.

  4. I can’t stand code that uses “this.” all over the place. It’s syntactically redundant and gives me the impression that the author doesn’t understand how member variables work.

    I also get a chuckle when I see someone decry a one-character prefix, but have no problem with using a five-character prefix instead.

  5. It will be lazy to admit this, but an advantage to using “this.” is that you get Intellisense when you are typing it. I often do this.

  6. yes, and in VB.NET is automatic, you just write “m_” and the intellisense suggest you all private fields defined with prefix “m_”

  7. Only use of this pointer I came across is to access the object in called methods like returning reference to object from the method e.g. overloaded assignment operator.
    m_ is my preferred naming convention for attributes. It is clean and instantly recognizable.

  8. I’m with Joe Stagner on this point … no prefix decoration on class members. It yields the very cleanest publication of the class. For years I’ve prefixed all parameters and locals with undersore which eradicates the possibility of any name conflicts.

  9. Why use prefixes, _ in particular? Microsoft specifically advice against it! Also, why use a prefix for private fields specifically, when you don’t have a prefix for constants. Or for statics. Or for readonlies?

    For those who call “this.” a five character prefix: The difference and beauty of “this.” is that you don’t have to use it unless there is a conflict.

    For those who think “this.” is hard to remember: Do you think _ is any easier? (As in universally easier, not just easier because it is what you’re used to?)

  10. I agree with the blogger. One needs to come up with creative names for parameters when using static classes since using “this” is not possible

  11. Microsoft recommends not using underscore as a prefix. I think that when it is a matter of taste it is always better to stick with the standards or recommendations.

  12. Still thinks it’s weird… Microsoft can recommend anything they want but as long as I see their internal developers use the prefix “_” for the past 10 years and are still using it to this day then it’s just confusing.

    Whatever Microsoft is saying it IS a standard and a recommendation by their employees. It’s a standard and recommendation by the majority of the community. Even Resharper does it by default.

    And I can understand why they use it, it’s easy, it’s useful and next to the “I” prefix for interfaces there are no prefixes so no cluttering. I can understand the hungarian notation being obsolute in the new age of software development. But that doesn’t mean that it’s evil enough to discourage using 2 useful prefixes.

Leave a comment