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.

score 59 · Answer 1 · answered Jul 12 '12 at 21:48

59

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

It eliminates conflicts with camel cased parameter names - no need to use "this"
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.

answered Jul 12 '12 at 21:48

Tom Bushell

5,865
4
45
60

13

I'm trying to understand the pros of the underscore, but I can simply say: Use 'this.': 1. It eliminates the need for "_". 2. It's a visual indicator that the internal persistent state of the object... You see my point. Your argument works both ways. – Noich Apr 30 '13 at 07:18
15

It does indeed. A couple more reasons I prefer _ over "this" - it's more compact, and it's not optional - the program won't compile if you forget the _ in a variable reference. But I think it's mainly personal preference... – Tom Bushell Apr 30 '13 at 20:29
3

Ad 2: Isn't this something syntax highlighting should do? – Jirka May 25 '13 at 16:15
Is it insanity to use underscored camelCase? i.e. `int _myInt` -- I've seen this done and actually quite like it. It very clearly distinguishes between method variables and private fields. – Sinjai Jul 26 '17 at 14:18
2

Actually if you check the source code of `.Net Core`, you will find a lot of places where they use `_xyz` convention. – Mohammed Noureldin Oct 30 '17 at 00:10
2

@MohammedNoureldin And some other cases, where they use `m_xyz`. – Adam L. S. Feb 04 '18 at 20:52
1

Microsoft's naming convention docs leave it up to the developer as to which naming convention is used for private variable. The important this here is to be consistent when picking a convention. I personally prefer "_" to "this.". However this does mean that when I use Quick Actions in VS I have to change the variable name as VS generates "this." private fields. – Bill Clyde Jan 18 '19 at 21:39

score 16 · Accepted Answer · answered Dec 27 '10 at 16:37

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.

score 8 · Answer 3 · answered Dec 27 '10 at 16:38

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

score 7 · Answer 4 · answered Jan 02 '11 at 11:05

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.

It definitely does not come from Java. In C/C++ identifiers starting with underscores are usually reserved for the compiler. — Ondrej Sotolar, Jul 03 '14 at 12:43

Naming convention for private fields

4 Answers4

Linked

Related