5

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

Improve this question
3
  • as you say, you shouldn't expose public fields, so it's really a moot point
    – AdamRalph
    Commented May 14, 2011 at 16:00
  • 4
    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
    Commented May 14, 2011 at 16:02
  • Apart from public static readonly fields - docs.microsoft.com/en-us/dotnet/standard/design-guidelines/…
    – Matthew Steeples
    Commented May 27, 2020 at 12:18

4 Answers 4

Reset to default
7

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.

Improve this answer
2
  • @Oded:lower case letter? MSDN says that public fields are Pascal so I am confused now
    – Miria
    Commented May 14, 2011 at 16:04
  • 1
    @Miria - fields should be private and start with lower case. Public members should be Pascal.
    – Oded
    Commented May 14, 2011 at 16:08
6

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

Improve this answer
3
  • Conventions are, of course, just conventions, but the MSDN conventions explicitly advise against prefixing with an underscore.
    – Aaronaught
    Commented May 16, 2011 at 15:01
  • 6
    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
    Commented May 16, 2011 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
    Commented May 16, 2011 at 17:42
2

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

Improve this answer
0

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.

Improve this answer
2
  • 1
    You mean stylecop.
    – Oded
    Commented May 14, 2011 at 15:52
  • Forgot about that one too. Fxcop does have many rules for casing (for parameters, methods, properties.
    – Lareau
    Commented May 14, 2011 at 16:22