What is the C# static fields naming convention?_问答_开发者

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;

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 C开发者_运维百科ompilation JIT etc?
Where does this style originate from? I have always associated it with C++, is that correct?

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

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;

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.

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

The convention is whatever your company's coding standards says it is.

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;

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;
    }
}

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.