SA1311: Warning should not be shown on private static readonly varibales


The following code is marked by SA1311 rule:

private static readonly Dictionary<Type, IProvider> providerInstances = new Dictionary<Type, IProvider>();

I think this is wrong, because the field is static readonly, but it's private. Only public static fields should start with an upper case letter. Or am I wrong?
Closed Jun 6, 2012 at 10:59 PM by andyr
Not a bug


andyr wrote Jun 6, 2012 at 10:59 PM

All static read only should start with an uppercase letter (almost a constant)

CarstenSchuette wrote Jun 7, 2012 at 8:42 AM

Unfortunately, MSDN naming rules only says that public and protected static members should use Pascal case:

"Do use Pascal casing for all public member, type, and namespace names consisting of multiple words." (http://msdn.microsoft.com/en-us/library/ms229043.aspx)

andyr wrote Jun 7, 2012 at 9:29 AM

Actually there is no mention of the word 'only' in that sentance.

CarstenSchuette wrote Jun 7, 2012 at 1:39 PM

They explicitly talk about public and protected fields. No need to use "only". If it's unclear, two rules are needed. I know lots of companies and programms that use pascal case only for public and protected static variables, and use camel case for private static fields. All these guys cannot use this rule.

CarstenSchuette wrote Jun 7, 2012 at 1:40 PM

In other words, the new rule is a breaking chance which is not covered by any MSDN documentation, because MSDN says nothing about private static fields.

andyr wrote Jun 7, 2012 at 2:32 PM

Correct. It's a new rule as opposed to a change to 1306 which it was earlier.

Turn it off if you cannot use it.

adamralph wrote Jun 8, 2012 at 7:53 AM

I realise this is closed, but IMHO, the default rule for private static readonly fields should be pascalCase.

The default for private readonly fields is pascalCase. The default for private static fields is pascalCase.

Why should this suddenly switch to CamelCase when the two are combined?

davedev wrote Apr 22, 2013 at 8:50 PM

Just voicing my opinion:
I disagree with the conclusion as well. For example, it doesn't make sense to have a warning on a private static field that backs a public static property.

public static Foo Something
Contract.Ensures(Contract.Result<Foo >() != null);
Contract.Ensures(Contract.Result<Foo >().Bar == true);

return something;

private static readonly Foo something = new Foo(bar: true);

Obviously I can't change "something" to "Something" because it will conflict. Using a different name for either will be inconsistent with instance property/fields. Also, I can't simply make it public because I'll lose the contracts. And contracts aren't the only reason that you may want to use this pattern.

PauloMorgado wrote Apr 23, 2013 at 2:06 PM

Private => pascalCase