Naming conventions for private members of .NET types [closed]

Answer 1

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.

Answer 2

There are two MSDN articles (here and here) about design guidelines that also contain naming conventions. Too bad they are restricted to "publically visible" things. They don't offer guidelines for naming non-public things and as far as I know Microsoft doesn't provide official naming guidelines for non-publics.

StyleCop (a Microsoft tool) is against using underscores in names. Two reasons I have heard from developers why they prefer to use the underscore:

• it clearly marks non-public members (type _ and intellisense will show you all the non-publics).
• it prevents conflicts between local variables (which are often also written in camelCase), method parameters and non-public fields.

IMO both are a good reason to use the underscore, however I don't like how it makes my code look so I don't use it either. I prefer to use only camelCase when possible and I add a this. in case of conflicts with local variables or method parameters.

We simply try to keep the coding style consistent within the team and project.

Answer 3

Please see the last paragraph of the MS Field Usage Guidelines.

Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.

Answer 4

Yes, the naming convention enforced by StyleCop (which enforces the MS coding rules) is 'no underscores, camel case' for private instance fields.

It is of note that constant/static readonly fields have the 'Pascal case' naming convention (must begin with uppercase but not be screaming caps).

The other naming conventions are holdovers from C++ style, which was the initial style used to code C# in since that's where the C# team came from.

Important Note: Whether or not you use this coding style is entirely up to the development team. It's far more important that everyone on the team use the same style than that any particular style be used.
OTOH, MS chose this style after much deliberation, so I use it as a tiebreaker. If there's no particular reason to go one way or another with a coding style, I go the way StyleCop goes.