Sign up ×

This question already has an answer here:

I read the following on the MSDN:

Use Pascal casing for all public member, type, and namespace names consisting of multiple words.

Note that this rule does not apply to instance fields. For reasons that are detailed in the Member Design Guidelines, you should not use public instance fields.

Use camel casing for parameter names.

Well it says it does not apply to instance fields so what applies to instance fields? I know I should not use them, but if I do, what is the correct convention? I guess it would be Pascal, but I'm not sure about it...

share|improve this question

migrated from May 15 '11 at 6:54

This question came from our site for professional and enthusiast programmers.

marked as duplicate by gnat, MichaelT, GlenH7, Dan Pichelman, Robert Harvey Oct 8 '13 at 22:12


as you say, you shouldn't expose public fields, so it's really a moot point –  AdamRalph May 14 '11 at 16:00
This is a bit like asking a policeman the correct way of stealing a car. If you're already doing something which is against the guidance, you shouldn't expect guidance on how to do it. –  Jon Skeet May 14 '11 at 16:02

4 Answers 4

The way I name them is:

private fields (I almost never have protected/private fields, I use protected/public properties instead): _camelCase protected/public fields/properties: PascalCase

The reason I have an underscore in front of the private fields is because I pass parameters into methods using camelCase so adding the underscore is only there to prevent variable name conflict (since I generally dislike using the this keyword inside classes).

share|improve this answer
Conventions are, of course, just conventions, but the MSDN conventions explicitly advise against prefixing with an underscore. –  Aaronaught May 16 '11 at 15:01
In 7 years I've yet to encounter a single naming conflict between underscore prefixed fields and anything in global namespace; if there ever is, I can still prefix with "this." . For all practical purposes, the underscore is safe for fields and prevents code from being littered with "this." when it's obvious that you're referring to the instance. –  Curtis Batt May 16 '11 at 15:45
Similar reasons, although I specifically prefix fields with an underscore when they back a property. If the underscored field name is found anywhere other than that property there needs to be a really good reason for it. –  Ken Henderson May 16 '11 at 17:42

As mentioned in the quoted text public fields should not be used. If you use them, use the same convention as for public properties = Pascal case.

There is no real convention for private instance fields because these fields are never exposed. There cannot be any convention collision between your convention and third party API or MS API. Convention for naming private instance fields is up to you but it should be consistent in the whole project (or all company projects).

share|improve this answer

I just follow the convention as told by the tool fxcop - Fxcop MSDN page

It's a bit easier then trying to remember all the rules all the time.

share|improve this answer
You mean stylecop. –  Oded May 14 '11 at 15:52
Forgot about that one too. Fxcop does have many rules for casing (for parameters, methods, properties. –  Lareau May 14 '11 at 16:22

Pascal Case seems to be the convention.

Of you look at the c# examples on MSDN, this is what they use.

StyleCop has all the MS coding conventions - if you leave the defaults it will tell you when you are not following them.

Rule SA1306 states that field names should start with a lower case letter.

share|improve this answer
@Oded:lower case letter? MSDN says that public fields are Pascal so I am confused now –  Miria May 14 '11 at 16:04
@Miria - fields should be private and start with lower case. Public members should be Pascal. –  Oded May 14 '11 at 16:08