C# coding standards for private member variables

Question

I saw two common approaches for coding standards for private member variables:

class Foo
{
    private int _i;
    private string _id;     
}


and 

class Foo
{
    private int m_i;
    private string m_id; 
}

I believe the latter is coming from C++. Also, many people specify type before the member variable: double m_dVal -- to indicate that is is a nonconstant member variable of the type double?

What are the conventions in C#?

Answer 1

I prefer to use your first example, or auto-properties like this, which avoid having the private fields defined in your class at all:

public String MyString { get; set; }

Use the prop snippet to make these REALLY fast.

Answer 2

Besides the two you mention, it is very common in C# to not have a prefix for private members.

class Foo
{
    private int i;
    private string id; 
}

That is what I use, and also what is recommended in Microsoft's internal naming guidelines.

Answer 3

As I recall from reading Framework Design Guidelines, there really is no set convention for private member variables, except that one should not use Hungarian notation and one should not capitalize the first letter of the variable name (use Camel-casing). There are quotes in the book that support both of your examples, as well as not using any prefix at all.

Personally, I prefer the "m_" prefix.

Answer 4

As noted by Brad Abrams: internal coding guidelines:

Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

Answer 5

I tend to go with the first convention, a simple underscore. I also don't specify the type in the name, because I've got Intellisense telling me what it is (I know, it can be a crutch).

Best to check with your coworkers or project teammates and just decide on a convention, some of them are kind of arbitrary.

Answer 6

While this document is by no means the gospel of naming conventions, it does reference a lot of industry standards and sets some reasonably sensible guidelines to follow. The one thing to remember is that guidelines aren't gospel, there are going to be situations where these "standards" just don't work. It's a great starting point though:

http://www.irritatedvowel.com/Programming/Standards.aspx

Answer 7

I prefer not using any prefix at all for member variables. For those declared outside the method, I use "this.memberVariableName" to distinguish them from those declared inside the method.

Answer 8

General guidance from Microsoft here:

http://msdn.microsoft.com/en-us/library/ms229002.aspx

Automatic properties in C# are great and I uses then when I can but there are cases where they don't work for me such as when doing type or value checking on a set method.

In general: use camel casing and don't prefix your name with anything such as underscore or a type prefix.

public int Age {get; set;}

or

private int age;
public int Age
{
    get { return age; }
    set
    {
        if(value < 0)
            throw new InvalidOperationException("Age > 0");
        age = value;
    }
}

Answer 9

I think the important principle here is that you're consistent. Use a "_" or "m" prefix if that's what you like to do and it's consistent with the rest of the code you're working with. Whatever you choose, stick with it and be consistent.

Answer 10

Best is to use whatever is already used in the project. If you start a new project, use whatever is most often used in the company.

Answer 11

In C++ identifiers beginning with _ are considered bad practice, they should be left for internal use. I think this is why prefixing a variable name with _ is sometimes considered bad practice in C# as well... although there is no reason why you can not do it since all of the .NET internals are encapsulated properly, unlike the C/C++ standard libraries.

Answer 12

I prefer underscore as prefix for private non const non readonly fields. Why? Reasons: 1. Simply looking on variable I can distinguish between field & local/parameter variable. Using "this." for all fields is not an option - its longer. 2. There is ambiguity between parameter and field:

class Foo
{
  private int id;
  public Foo(int id)
  {
    id = id; //Will compile and work fine. But field will not be initialized.
  }
}

Answer 13

I personally have always used your first example of:

    public class Foo
    {
        private int _i;
        private string _id;
    }

In fact, that's what my entire team uses. Additionally the one you mentioned m_dVal is known as Hungarian Notation, here is the Wikipedia Entry. Hungarian Notation is actually against our teams' coding standards, so I never use it.