Naming conventions for private members of .NET types

Question

Normally when I have a private field inside a class or a struct, I use camelCasing, so it would be obvious that it's indeed private when you see the name of it, but in some of my colleagues' C# code, I see that they use m_ mostly or sometimes _, like there is some sort of convention.

Aren't .NET naming conventions prevent you from using underscores for member names?

And when you mention the MS naming conventions or what not, they tell you theirs is the best way, but don't explain the reasoning behind it.

Also when I am the owner of some code, where I clearly use camelCasing for private members, when they have to make a minor modification to the code, they stick in their conventions instead of following whatever conventions are there.

Is this a controversy?

Solution 1

Technically, underscores are a violation of .NET conventions (or at least used to be -- see comment thread), but Microsoft programmers themselves often use underscores, and many examples in the documentation use underscores. I think it's very helpful to be able to see at a glance which variables are member variables (fields) and which are local. The underscore really helps with this. It also nicely separates private member variables from local variables in intellisense.

Please see this very useful page for .NET naming conventions:

http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

And here's a page with Microsoft's official recommendations:

https://msdn.microsoft.com/en-us/library/ms229045%28v=vs.110%29.aspx

Solution 2

The .Net framework guidelines allow for a _ or m_ prefix on private field names because the provide no guidance on private fields. If you look at the BCL in reflector you'll notice a prefix is the most prevalent pattern.

The Reference page for naming fields is located here. Notice the guidelines only specify usage for public and protected fields. Private fields are simply not covered.

Solution 3

I typically prefix private member variables with an underscore.

It just makes them easier to spot when you're trying to read the code and it's allowed by the Microsoft Guidelines:

public class Something
{
    private string _someString = "";

    public string SomeString
    {
        get
        {
            return _someString;
        }
        set
        {
            // Some validation
            _someString = value;
        }
    }
}

Like others have said, the more important thing is to be consistent. If you're on a team that has a coding standard that does things the m_ way, don't try to be a rebel and do yours another. It will just make things more difficult for everybody else.

Solution 4

well, microsoft is not taking part for any of the 2 options. If on Visual Studio you encapsulate a field using "refactor->Encapsulate Field..." for

private string _myVar

and

private string myVar

both of them generates a propery like this

public string MyVar
{
    get { return myVar; }
    set { myVar = value; }
}

So for microsoft it's the same :-) It's only a question of reaching an agreement with the development team so everyone uses the same approach.

Normally I never use private fields except very specific situations. I encapsulate private fields with protected properties. Better for inheritance and more clear IMHO.

Solution 5

Even in the BCL you see a lot of inconsistency with naming conventions, some classes have "_", some "m_" and some just the pascal case version of the property.

Underscore is good because you prevent accidental stackoverflows, although more recent versions of Visual Studio warn you about this anyway. They also appear first in your intellisense, avoiding the need to riddle your code with this.someProperty or search through the entire list.

As long as the team agrees on one standard it doesn't make a whole lot of difference, but having used underscores for 5+ years I personally wouldn't want to return back to the alternatives.

If you own the codebase and maintain it, I would insist they use your standards. If they don't then simple refactor it combined with a polite email why you've done it.

View more solutions