What is the C# static fields naming convention?

Question

I have recently started using ReSharper which is a fantastic tool. Today I came across a naming rule for static fields, namely prefixing with an underscore ie.

private static string _myString;

1. Is this really the standard way to name static variables? If so is it just personal preference and style, or does it have some sort of lower level impact? Eg Compilation JIT etc?
   
2. Where does this style originate from? I have always associated it with C++, is that correct?

Answer 1

The Microsoft guidelines are silent about private fields, they are only concerned with publicly visible members.

Common conventions are camelCase, _camelCase and even sometimes the hangover from C++/MFC m_camelCase.

If you use camelCase without a prefix, your property backing fields will differ from the property name only in case, which is not a problem in C#, but won't work in a case-insensitive language like VB.NET.

So many people, including myself, like to use an underscore prefix so that the same standards can be used in all languages. In my experience, underscore is much more common than m_.

Answer 2

According to MSDN , use Pascal Case for static fields. I always chuckle when MSDN and StyleCop contradict each other :).

So if you are following MSDN standards, the correct way is:

private static string MyString;

Answer 3

According to StyleCop (and with the default settings), the correct way to name most fields (as specified below) is with a lowercase letter at the start.

SA1306: FieldNamesMustBeginWithLowerCaseLetter

... Field and variable names must begin with a lower-case letter, unless the field is public or internal, const, or non-private and readonly. In these cases, the field should begin with an upper-case letter.

See also SA1309: FieldNamesMustNotBeginWithUnderscore .

Answer 4

It's actually the style for a private field, static or not. (At least in ReSharper)

Answer 5

约定是您公司的编码标准所说的。

Answer 6

The problem I have with the MSDN guideline (use Pascal case) is that it results in there being no distinction between a private static variable and a public (non-static) property. The same issue would arise for static properties - no distinction between static and non-static.

Perhaps this is deliberate?

One way out of this would be to use the same standard for statics as for non-statics but to always qualify use of statics by prefixing with the class name. It may be a few extra characters to type, but it makes the code more readable. For example:

public class Employee
{
    private static Int32 thresholdPercentage = 5;
    public static String TooMuchMessage = "Unacceptable pay rise - sorry!";

    private Decimal _salary = 0.0m;

    public void RaiseSalary(Int32 raiseAmountPercentage)  
    {
        if (raiseAmountPercentage > Employee.thresholdPercentage)
            throw new ApplicationException(Employee.TooMuchMessage);

        _salary *= 1 + (raiseAmountPercentage / 100);

        return;
    }
}

Answer 7

UPDATE FOR 2021

Per C# Coding Conventions published 2021 from Microsoft , private static variable should start with s_ prefix followed by camel case. So, it should look like below:

private static string s_myString;

Answer 8

For static fields , I've settled on StaticPascalCase (eg. StaticPersonCache ) as it clearly sets it apart from an instance variable. This includes private static fields as well as static fields with other visibility modifiers.

For static variables it's less of a concern to me to indicate the public/private visibility through the name than it is to indicate how the variable operates among instances. Also, since there are not (and really should not be) many Static variables the 'Hugarian-like' modifier is not applied often.

Similarly, for thread-static variables ([ThreadStatic] or ThreadLocal) the convention I use is TS_UpperCamelCase (eg. TS_Random ). Once again, this "break" from norms conveys very important information that other developers might fail to see on first glance. The name is thus used as a cautionary flag, of sorts.

I use ReSharper and have adjusted the warnings/hints accordingly; most other naming conventions are left at the ReSharper default settings.

My selection of such "non standard" conventions for static/thread-static fields (note: Microsoft uses TS_ in some code in the .NET library) is because I've run into more than one 'quirk' due to misidentification of Static/ThreadStatic/Instance variables: that's much harder to do with StaticX , TS_X , and _x .

Answer 9

1. There is no definitive standard rule for variable names. There are C# compiler requirements for what's allowed and what's not (eg can't start with a number), but programming language style rules are generally left up to the programmers / organizations. ReSharper has pre-defined style rules; however, they are merely set up as defaults in a convention over configuration approach and are modifiable.

2. You can take a look at this Wikipedia article to see the history behind Camel Casing .

Answer 10

Other answers here are a bit confusing.

From .NET standard :

DO use PascalCasing in field names.
The field-naming guidelines apply to static public and protected fields.

So example will be: MyStaticVariable, ActiveUserCount, etc.