Question

通常当我在一个类或一个结构体中有一个私有字段时，我使用camelCasing，所以很明显，当你看到它的名字时它确实是私有的，但在我的一些同事的C＃代码中，我看到了他们大多使用m_或有时使用_，就像有某种约定一样。

.NET命名约定是否阻止您使用成员名称的下划线？

当你提到MS命名惯例或者什么不是时，他们会告诉你他们的最佳方式，但不解释其背后的原因。

此外，当我是某些代码的所有者时，我明确地将camelCasing用于私有成员，当他们必须对代码进行微小的修改时，他们会坚持他们的约定而不是遵循任何约定。

这是一个争议吗？

Answer 1

.Net框架指南允许在私有字段名称上使用_或m_前缀，因为它不提供有关私有字段的指导。如果你看一下反射器中的BCL，你会发现前缀是最普遍的模式。

命名字段的参考页面位于here。请注意，指南仅指定公共字段和受保护字段的用法。私人领域根本没有被覆盖。

Answer 2

从技术上讲，下划线违反了.NET约定（或至少曾经是 - 请参见注释线程），但Microsoft程序员自己经常使用下划线，文档中的许多示例都使用下划线。我认为能够一目了然地看到哪些变量是成员变量（字段）以及哪些是本地变量是非常有帮助的。下划线确实有助于此。它还可以很好地将私有成员变量与intellisense中的局部变量分开。

请参阅这个非常有用的.NET命名约定页面：

http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

这是微软官方建议的页面：

https://msdn.microsoft.com/en-us/library/ms229045%28v=vs.110%29.aspx

Answer 3

我通常使用下划线为私有成员变量加前缀。

当您尝试阅读代码时，它们更容易被发现，并且Microsoft指南允许这样做：

public class Something
{
    private string _someString = "";

    public string SomeString
    {
        get
        {
            return _someString;
        }
        set
        {
            // Some validation
            _someString = value;
        }
    }
}

像其他人所说的那样，更重要的是要保持一致。如果你是一个拥有编码标准的团队，以m_的方式做事，不要试图成为反叛者而是做另一个。这会让其他人的事情变得更加困难。

Answer 4

好吧，微软没有参与任何2个选项。如果在Visual Studio上使用“refactor-＆gt; Encapsulate Field ...”封装了一个字段，用于

private string _myVar

和

private string myVar

他们两个都会像这样生成一个属性

public string MyVar
{
    get { return myVar; }
    set { myVar = value; }
}

因此，对于微软来说，它是相同的:-)这只是与开发团队达成协议的问题，所以每个人都使用相同的方法。

通常我从不使用私人字段，除非是非常具体的情况。我用受保护的属性封装私有字段。更好的继承和更明确的恕我直言。

Answer 5

即使在BCL中，您也会发现与命名约定有很多不一致，有些类有“_”，有些类有“m_”，有些只是属性的pascal案例版本。

下划线很好，因为你是prevent accidental stackoverflows，尽管不管怎样，最新版本的Visual Studio会对此发出警告。它们也首先出现在您的智能感知中，无需使用this.someProperty谜语代码或搜索整个列表。

只要团队对一个标准达成一致意见就不会产生很大的不同，但是使用了超过5年的下划线我个人不会想要回到替代品。

如果你拥有代码库并进行维护，我会坚持使用你的标准。如果他们没有，那么简单的重构它与礼貌的电子邮件结合为什么你已经完成它。

Answer 6

请参阅MS Field Usage Guidelines的最后一段。

不要为字段名称或静态字段名称应用前缀。具体而言，请勿对字段名称应用前缀以区分静态字段和非静态字段。例如，应用g_或s_前缀不正确。

Answer 7

没有约定阻止您使用有效的标识符名称。重要的是一致。我对所有私有变量使用“_”，虽然“正确的方式”（例如ReSharper）似乎要求你以小写字母开头声明它们，并通过使用“this”来区分参数和成员。

Answer 8

我真的不相信案例变量和方法有任何最好的方法。重要的是你和你的团队是一致的。 .NET命名约定与Microsoft指定它们的方式非常相似，但有些人更喜欢其他约定......

作为个人而言，我试图用私有变量和方法加上“_”，然后使用骆驼套管，受保护的变量和驼峰套管中的方法以及带有pascal套管的公共变量和方法，但这只是我。

Answer 9

是的，StyleCop强制执行的命名约定（强制执行MS编码规则）是私有实例字段的“没有下划线，骆驼案例”。

值得注意的是，常量/静态只读字段具有'Pascal case'命名约定（必须以大写字母开头但不是尖叫上限）。

其他命名约定是C ++样式的延续，这是用于编写C＃的初始样式，因为这是C＃团队的来源。

重要说明：您是否使用此编码样式完全取决于开发团队。更重要的是团队中的每个人都使用与任何特定风格相同的风格 OTOH，MS经过深思熟虑后选择了这种风格，因此我将其用作决胜局。如果没有特别的理由以这种或那种方式采用编码风格，我会采用StyleCop的方式。

Answer 10

有两篇关于设计指南的MSDN文章（here和here）也包含命名约定。太糟糕了，他们被限制在“公开可见”的东西。他们没有提供命名非公开事物的指南，据我所知，微软没有为非公众提供官方命名指南。

StyleCop（Microsoft工具）反对在名称中使用下划线。我听到开发人员为什么喜欢使用下划线的两个原因：

它清楚地标记了非公开成员（类型_和智能感知会向您展示所有非公开成员）。
它可以防止局部变量（通常也用camelCase编写），方法参数和非公共字段之间的冲突。

IMO都是使用下划线的一个很好的理由，但我不喜欢它如何使我的代码看起来所以我也不使用它。我希望在可能的情况下只使用camelCase，如果与局部变量或方法参数冲突，我会添加this.。

我们只是努力使编码风格在团队和项目中保持一致。

.NET类型的私有成员的命名约定

10 个答案: