C#静态字段的命名规范是什么?

45

我最近开始使用ReSharper,这是一个很棒的工具。
今天我发现了一个关于静态字段命名规则的规定,即在前面加下划线作为前缀,例如:

private static string _myString;
  1. 这是否真的是命名静态变量的标准方式?如果是,那么这只是个人偏好和风格,还是有一些低级影响?例如编译JIT等。
  2. 这种风格起源于何处?我一直将其与C++相关联,这正确吗?
10个回答

32

微软的指南没有提及私有字段,它们只关注公开可见的成员。

常见的惯例是使用驼峰式命名法、_驼峰式命名法,甚至有时还保留了来自 C++/MFC 的 m_camelCase 风格。

如果您在不加前缀的情况下使用驼峰式命名法,则属性支持字段与属性名称仅在大小写方面不同,在 C# 中这并不是问题,但在 VB.NET 这样的大小写不敏感的语言中无法正常工作。

因此,很多人,包括我自己,喜欢使用下划线前缀,以便在所有语言中都可以使用相同的标准。根据我的经验,下划线比 m_ 更常用。


2
你为什么认为微软指南只关注公开可见成员?http://msdn.microsoft.com/en-us/library/d53b55ey%28v=VS.71%29.aspx - dcp
1
@dcp 我同意你提供的最新 MSDN 版本并不是很明确,但早期版本则有所说明。例如,VS2008 帮助文档中写道:“本主题中描述的大写规范可帮助开发人员理解和使用库。”(这似乎排除了私有成员),以及“名称不能仅因大小写而异”(对于 C# 私有成员显然不正确)。 - Joe
实际上,我的观点是MSDN确实给了我们一个关于如何命名静态变量的指南,而指南是使用PascalCase。当然,正如其他人指出的那样(以及我在回答中所暗示的),StyleCop希望它们以小写字母开头。 :) 你不喜欢一致性吗? - dcp
7
但是如果MSDN指南仅适用于公开可见成员,则没有不一致性,只有MSDN文档中的歧义。 - Joe
在最近的指南中,微软更强烈地推荐在私有变量名称前使用下划线,以避免引入新关键字到语言中时出现破坏性的更改,而我们最近看到了更多这样的情况。 - Haighstrom

31

根据MSDN的说法,对于静态字段应使用Pascal Case。每当看到MSDN和StyleCop相互矛盾时,我总是会笑出声来 :)

因此,如果您遵循MSDN标准,则正确的方法是:

private static string MyString;

在这种情况下,返回 MyString 值的公共静态属性应该被命名为什么? - O. R. Mapper
@O. R. Mapper - 根据我回答中的链接,属性和静态字段都使用帕斯卡命名法。因此,我会遵循这个惯例。 - dcp
1
你的评论巧妙地避免了指出这意味着属性必须与字段完全相同的名称,而这当然是不可能的 ;) - O. R. Mapper
@O. R. Mapper - 是的,说得好:). 在这种情况下,为了避免命名冲突,您可能希望使用不同的名称来命名静态字段和静态属性。 - dcp

19

根据StyleCop的规定(默认设置),大多数字段的正确命名方式(如下所述)是以小写字母开头。

SA1306: FieldNamesMustBeginWithLowerCaseLetter

... 字段和变量名称必须以小写字母开头,除非该字段为public或internal、const或非私有和只读。在这些情况下,字段应以大写字母开头。

另请参见SA1309: FieldNamesMustNotBeginWithUnderscore


17

2021年更新

根据微软2021年发布的C#编码规范private static变量应以s_前缀开头,后跟驼峰命名法。因此,应该如下所示:

private static string s_myString;

1
我喜欢这种约定;使用 s_ ...private static,使用 _...private - Ola Ström
2
2023年 - 已验证,仍然是当前的惯例,并且非常合理。点赞。 - Brian

11

实际上,这是私有字段(无论是否静态)的风格(至少在ReSharper中)。


是的,具体来说是 private。如果您在受保护或公共字段上使用下划线,它将不符合 CLS。 - Matt Greer
2
ReSharper自带一些默认的样式规则(基于JetBrains的员工决定的惯例,这些默认值可以更改)。 - user2864740

6
惯例是按照公司的编码标准来确定的。

4
我对MSDN准则(使用Pascal case)的问题在于,这样会导致私有静态变量和公共(非静态)属性之间没有区别。对于静态属性也会出现同样的问题-无法区分静态和非静态。
也许这是故意的?
解决这个问题的一种方法是对静态和非静态使用相同的标准,但始终通过在类名前缀中加上限定符来限定静态的使用。这可能需要多输入一些字符,但可以使代码更易读。例如:
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;
    }
}

1
ReSharper 将会在默认设置下警告这个类名是多余的。 - user2864740

2
对于静态字段,我选择使用StaticPascalCase(例如StaticPersonCache)作为命名规范,以明确它与实例变量的区别。这包括私有静态字段以及具有其他可见性修饰符的静态字段。
对于静态变量而言,相对于通过名称指示公共/私有可见性,更重要的是指示变量在实例之间的操作方式。此外,由于静态变量不应该有太多(而且真的不应该有太多),因此“匈牙利式”修饰符并不经常使用。
同样地,对于线程静态变量([ThreadStatic]或ThreadLocal),我使用TS_UpperCamelCase(例如TS_Random)作为约定。再次强调,这种“偏离”常规的命名传达了其他开发人员可能无法在第一眼看到的非常重要的信息。因此,名称被用作一种警示标志。
我使用ReSharper并已相应地调整了警告/提示;大多数其他命名约定都保留了ReSharper默认设置。
我选择这样的“非标准”约定来命名静态/线程静态字段(注意:Microsoft在.NET库中的某些代码中使用TS_),是因为我曾遇到过由于错误识别静态/线程静态/实例变量而引起的多个“怪异”问题:使用StaticXTS_X_x更难出错。

0

这里的其他答案有点令人困惑。

来自.NET standard

在字段名中使用PascalCasing。
字段命名指南适用于静态公共和受保护字段。

因此,示例将是:MyStaticVariable、ActiveUserCount等。


0
  1. 变量名没有明确的标准规则。C#编译器有允许和不允许的要求(例如不能以数字开头),但是编程语言风格规则通常由程序员/组织自行决定。ReSharper具有预定义的样式规则;然而,它们仅被设置为约定优于配置方法中的默认值,并且可以进行修改。

  2. 您可以查看这篇维基百科文章,了解驼峰命名法背后的历史。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接