Naming convention for private fields

Question

First, I know this question has been asked several times before and that in the end, it is mostly a matter of personal preference, but reading all the threads about the subject, some things are not clear to me.

Basically, something that most people agree with at least is that public member should be PascalCased while private members should be lowerCamelCased.

The matter that usually brings debate is whether or not to prefix the private members by an underscore, or anything else. Prefixing violates several StyleCop rules (which can obviously be turned off though)

The rationale to not prefixing is that you should use this. to prefix instead.

The problem I have is that I don't understand how it is making a difference? I mean, it is not like you can't use this on a public member anyway inside a class.

Let's imagine a class Customer, looking like this:

class Customer
{
    private int age;

    public int Age
    {
        get { return this.age; }
        set { this.age = value; }
    }
}

(Obviously, in such a simple case, I could use an autoproperty, but that's just an example).

If I added a second property inside this class, nothing would prevent me to refer to it using this.Age (the public property) rather than this.age (the private field). Sometimes, it could even be wishable, if some validation or formatting was applied at the getter level.

Also, if some other properties of my class needed to modify the customer's Age, it would make sense to use the property rather than the backing field directly as the setter could also implement some business rules validations, right?

In other words, I really don't see how the this keyword avoids the confusion between private backing members and public properties as this can be used on both and IntelliSense shows both?

Thanks.

Answer 1

You are quite right. It doesn't.

Using this is a way to ensure you are using the class member, in case of naming conflicts (say a parameter name that is identical to a field name).

For me, pascal casing public members and camel casing private members has always been enough of a convention to work well.

Answer 2

I strongly prefer the leading "_" convention for private fields, even though it does not follow MS conventions:

1. It eliminates conflicts with camel cased parameter names - no need to use "this"

2. It's a visual indicator that the internal persistent state of the object is being read, or - more importantly - being written. It's a flag saying "this has side effects outside of the particular method I happen to be looking at", which is very important to know when looking at unfamiliar code.

Answer 3

Using this.age could help distinguish between the backing store of your Age property and an age parameter for a method on your object:

public bool CheckIfOlderThan(int age)
{
   // in here, just using "age" isn't clear - is it the method parameter? 
   // The internal field?? Using this.age make that clear!
   return (this.age >= age); 
}

Of course, in this case, you could also give your parameter a less confusing name to avoid any clashes....

But in the actual definition of the property - reading and storing its value in the backing store - adding the this. doesn't really add anything. Some people I know just prefer to use the this. prefix all the time - not just when it's needed - personal preference, really...

Answer 4

Prefixing private fields with underscore is basically the same thing as using "this.". However underscore is faster to use, shorter and more elegant to me (this comes from Java I believe).

Having the same names for function parameters and private fields seems a bit tricky to me. Not only once have I forgot to use "this" which resulted in nasty NullPointerException (yes, I did java someday... :) ).

As far as I know it doesn't violate any FxCop rule, as it's not a hungarian notation.