In C#, what is the generally accepted way to refer to member properties within the class?

Question

Have read through the MSDN naming guidelines and could not find a clear answer, other than that you should try to avoid underscores in general. Let's say I have the following:

public class Employee
{
    private string m_name;  //to store property value called Name

    public string Name
    {
        get { return m_name; }
        set { m_name = value; }
    }

    public void ConvertNameToUpper()
    {
        //by convention should you use this
        return m_name.ToUpper();

        //or this
        return Name.ToUpper(); 
    }
}

What is the proper naming convention for m_name in the above? For example, in code I inherit I commonly see:

• m_name
• _name
• name
• myName or some other random identifier

Which one (or another) is most commonly accepted?

As a follow-up, in the methods of the class, do you refer to the internal (private) identifier or to the public property accessor?

Answer 1

First of all - for the simple get/set cases I would recommend that you use automatically implemented properties. If you do that the compiler will generate the underlying variable, and you only reference the property itself.

Other than that, I suggest you pick one of the above or anything similar and just stick to that. The company I work for uses vName where the "v" indicates that this is the value of the property.

Answer 2

The most common one I've seen in example code is a simple _ prefix.

However, what really matters is that the team agrees what the standard is and sticks to it.

Answer 3

I think that, whatever naming convention you use, the most important thing is that you stay consistent. I mean, if you choose to name private members like _name , then always do it like this instead of once using _name, and the other time m_name. I personally use the underscore-prefix convention. (one of the reasons is because I use NHibernate, and NHibernate has a 'field.camelcase-underscore' access strategy.

For your other question: It depends on what you want to do.
Does your property contain extra logic, and do you want this logic to be executed when you refer it ? Then use the property. You don't want to execute the logic ? Use the field. Eric Lippert has written a post regarding this on his weblog.

For your folluw-up: it all depends on the situation. If your property contains some additional logic, and you don't want to execute that additional logic when accessed from within the class, then use the backing field ...

Answer 4

If you can't use an automatically implemented property as Brian Rasmussen suggest and you have to have a private member, then I would recommned the underscore prefix, _name.

In intellisense, it's not immediately obvious whether an item is a parameter, local or private member as they all have the same symbol (blue cube). If, however, you move cursor to a particular item then the tooltip tells you which of these it is.

I find the underscore prefix is a handy visual aid which makes it immediately obvious that it is a private member without having to move the cursor.

Answer 5

On one hand I agree you should use company standards on the other hand I would try to adhere to industry standards.

Answer 6

I would echo previous answers in that you should stick with a scheme that your team uses, or if you are not in a team, be consistent with whatever you do use.

Personally, I use the the underscore prefix as I find it gives me a good visual cue.

Answer 7

I think the generally accepted naming convention is solely to make the name meaningful (and the code clean and simple). In my opinion, if the identifiers in my code need visual cues for any reason, it's too complex and the names are usually not entirely accurate.

I've worked on code that required a manual just to read... "m" meant class-level, "p" meant parameter, etc. The naming convention was developed to make the code easier to read but it ended up doing just the opposite because developers ran with the implication that "good" naming conventions meant readable code.

Just make sure this Dennis Green (former Arizona Cardinal coach) quote applies to your identifiers: "They are who we thought they were!"

Answer 8

I try to only access the member variable when I have to, such as when the property is read-only or I want to bypass any setting logic.

One reason for this is that if you do add logic to the setter later, you will most likely want it to be used everywhere.

Answer 9

I used to be very against the '_' prefix, but it really is useful with intellisense, when you want to quickly access a member field without having to type many letters.

Answer 10

For class-level variables, our coding standards say use mVariableName or m_VariableName. The main thing is to follow your company/teachers/etc. coding standards/practices.

I, personaly, only access the variable through its getter/setter if it has one. Even if the variable is only used internally in the class, I use the automatic properties. This way, I add a layer of abstaction wich means less code to refactor if I changed something.

BTW, your void function can't return a string..... :-)

Answer 11

I use Style Cop which enforces some styles on your code. I find this very useful and all my team members also use this.

While there are great discussions around the use of Style Cop, one thing I would suggest is that if you use Style Cop that is to leave all styles enabled. This way when you share between users it makes things a lot easier.

One of the things this inforces is that you can not name your private fields with underscores. So I generally use camelCase when writing private fields and then PascalCase for public Properties:

private string name;
public string Name
{
    get { return this.name; }
    set { this.name = value; }
}

Style Cop also enforces the use of this. which makes things a lot easier to read.

Answer 12

I just wanted to add that the MSDN naming guidelines doesn't specify this because it only has guidelines for the public interface (i.e. property names, public methods, public method arguments, etc...) They don't care about private member style, so as far as Microsoft is concerned, you can use whatever you and your team wants.

Answer 13

First of all, I, and many others I have worked with have done away with the use of prefixing private members with "m_". Next, whenever I refer to the private member within the class, I usually use the word this as in "this.privateMemberVariableName". Using this is enough to distinguish that the variable is not a local variable or a variable passed as a parameter within the method.

I do refer to the public property name if it contains logic that is other than just referring to the private member variable, such instancing a connection or saving the property value in a view state.

Answer 14

The framework Design guidelines book says that you shouldn't prefix your variables with _ - you should just use a lower case for the name of the variable, and Code Complete 2nd edition I believe says you shouldn't prefix your variables with m_.