CODEWITHSUNDEEP
c#naming-conventionsclass-design
nshaw
nshaw

Reputation: 2625

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

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:

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?

Upvotes: 2

Views: 1078

Answers (14)

Surgical Coder
Surgical Coder

Reputation: 1084

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

Upvotes: 0

cyclo
cyclo

Reputation: 377

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.

Upvotes: 0

Frederik Gheysels
Frederik Gheysels

Reputation: 56934

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

Upvotes: 14

NotDan
NotDan

Reputation: 32213

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.

Upvotes: 0

Coding Monkey
Coding Monkey

Reputation: 1000

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.

Upvotes: 4

Muad'Dib
Muad'Dib

Reputation: 29196

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

Upvotes: 0

DavidN
DavidN

Reputation: 5197

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.

Upvotes: 1

Adam Ruth
Adam Ruth

Reputation: 3655

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.

Upvotes: 0

Austin Salonen
Austin Salonen

Reputation: 50215

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!"

Upvotes: 0

Andy
Andy

Reputation: 5268

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.

Upvotes: 0

Chuck Conway
Chuck Conway

Reputation: 16435

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

Upvotes: 0

Adam Ralph
Adam Ralph

Reputation: 29956

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.

Upvotes: 2

AnthonyWJones
AnthonyWJones

Reputation: 189447

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.

Upvotes: 3

Brian Rasmussen
Brian Rasmussen

Reputation: 116401

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.

Upvotes: 5

Related Questions