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

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.