What is the C# static fields naming convention?

c# .net variables coding-style

46,507

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

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

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

Solution 4

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

Solution 5

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

View more solutions

46,507

Author by

Matt

Updated on November 07, 2020

Comments

Matt over 3 years
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?
dcp almost 14 years

Why do you think the Microsoft guidelines are only concerned with publicly visible members? msdn.microsoft.com/en-us/library/d53b55ey%28v=VS.71%29.aspx
Matt Greer almost 14 years

Yes, specifically private. If you have the underscore on a protected or public field, it will not be CLS compliant. msdn.microsoft.com/en-us/library/k5645wwb(VS.80).aspx
Joe almost 14 years

@dcp I agree that the latest MSDN version you link isn't very explicit, but earlier versions were. For example VS2008 help says "The capitalization conventions described in this topic make it easy for developers to understand and work with a library." (which seems to exclude private members), and "Names cannot differ by case alone." (which is patently not true for private C# members).
dcp almost 14 years

Actually, my point was that MSDN does actually give us a guideline on how to name static variables, and the guideline is to use PascalCase. Of course, as somebody else pointed out (and as I alluded to in my answer) StyleCop expects them to begin with a lowercase letter. :) Don't you just love consistency :)?
Joe almost 14 years

@dcp - but if the MSDN guideline is only intended to apply to publicly-visible members there is no inconsistency, just ambiguity in the MSDN docs.
user2864740 about 7 years

ReSharper comes with some default style rules (based on conventions the folks at JetBrains decided make good defaults) that can changed.
user2864740 about 7 years

ReSharper will warn that the class name is redundant with default settings.
O. R. Mapper over 5 years

In that case, what should a public static property be named that returns the value of MyString?
dcp over 5 years

@O. R. Mapper - According to the link in my answer, properties and static fields both use Pascal case. So I would follow that convention.
O. R. Mapper over 5 years

Your comment skillfully avoids pointing out that that implies the property would have to have exactly the same name as the field, which is, of course, impossible ;)
dcp over 5 years

@O. R. Mapper - Yes, good point :). In that case, you would probably want to use a different name for the static field vs the static property to avoid the naming conflict.