C# .NET 实例变量命名约定？答案

【问题标题】：C# .NET instance variable naming convention?C# .NET 实例变量命名约定？
【发布时间】：2011-12-21 19:58:47
【问题描述】：

我正在一家企业做一个小型实习，在他们的代码中，我找到了这样命名的类：

public class FlagsConfig
{
    private static FlagsConfig _instance; 
}

_instance 是 C# 中的任何命名约定吗？

我会问开发人员，但他们今天和下周都在某个课程上。

【问题讨论】：

在此处阅读答案时有所保留：遵循您组织的现有代码 - 不要试图违背常规。如果你有机会提供意见，那就去做吧，但不要把精力浪费在琐碎的事情上，比如与现有的命名约定作斗争（除非你与现有代码充分隔离），或者尝试在现有代码中修改它们（除了代码审查预检，修改它以适应现有约定）。当你这样做时，你会非常没有生产力，并且会激怒人们:)
我不认为@Shogoot 打算改变它！他质疑它是什么很好。
对于大多数私有字段，在变量名前使用_下划线是合适的。
@Braveyard：他也可以使用驼峰式表示法。这取决于组织对组织的编码策略。
我永远不会明白为什么在成员变量中使用 _ 或某些 m 前缀。如果它使任何东西对您来说更具可读性，这意味着您的代码很糟糕，类和方法太大并且您从未听说过 SRP。

标签： c# .net naming-conventions naming

【解决方案1】：

您的同事是前 VB 开发人员吗？在 VB.Net 中，下划线经常用于属性或类的私有成员。由于VB不区分大小写，所以不能用大小写来区分。

Private _someValue As Boolean
Protected Property SomeValue() As Boolean
    Get
        Return _someValue
    End Get
    Set(ByVal value As Boolean)
        _someValue = value
    End Set
End Property

更新：顺便说一句，.NET 源代码中的许多类都使用这种约定。尤其是System.Web。

【讨论】：

【解决方案2】：

根据StyleCop [Microsoft 的样式/约定检查工具）不应该这样做。见：http://stylecop.soyuz5.com/SA1309.html

另外，问题可能是To underscore or to not to underscore, that is the question的欺骗

【讨论】：

【解决方案3】：

_instance 是 C# 中的任何命名约定吗？

首先，很多人都参考了命名准则。请注意，其中许多准则仅适用于类型的 public 表面区域。像您提到的私有成员是内部实施细节，因此受制于产生它们的组织的政策，不受人们期望在公共元素中看到的框架设计指南的约束。

对于私有实现细节，下划线前缀在许多组织中很常见。我个人认为没有必要，但有些人似乎喜欢它。

然而重要的是，即使对于私有实现细节，您也不应该使用两个下划线。 C# 编译器团队保留使以两个下划线开头的任何单词具有我们选择的任何含义的权利在该语言的某些未来版本中。这是我们的“逃生舱”，以防我们真的、真的需要添加一个新的非上下文保留关键字并且真的、真的不想破坏任何现有代码。

这在 C# 4 规范的第 2.4.2 节中有记录。

【讨论】：

这就是未记录的__arglist和TypedReference关键字都以__开头的原因吗？

【解决方案4】：

是的，这是私有字段的通用命名标准：

http://csharpguidelines.codeplex.com/

我碰巧同意@JonSkeet 的观点，即下划线很混乱，但 AFAIK 是 MS 标准。他链接到的文档不在您的图书馆中使用下划线表示，但我相信这是指公共成员。

更新

第一个链接实际上主张相反；不要使用下划线。我的错误，但它仍然是一个有用的资源。

出于对 Skeet 先生的尊重，我进一步关注了他的链接：http://msdn.microsoft.com/en-us/library/ms229012.aspx，其中还指出您不应使用下划线，但该指导适用于静态、受保护和公共成员，但不一定适用于私人成员。

底线：是的，这是一个通用标准，但在尝试查找/使用外部标准之前，请先使用任何内部商定的标准。

【讨论】：

该编码标准实际上不是说不要对私有字段使用下划线吗？尽管正如其他人所说，要走的路总是先看看你的团队编码标准:-)
由于业务 im @ 使用 _ 来表示类的私有字段，因此不使用它不是问题。无论如何，这个问题被回答为使用 _ 是一个命名约定，即使它没有被您链接的文档所推荐。
在这种情况下，答案是……是的。这是一个通用的命名标准。例如，它是流行的 c# 工具 ReSharper 的默认设置
您显示的后面的链接说：“字段的命名准则适用于静态公共和受保护字段。”
第一个链接中的备忘单非常有用。

【解决方案5】：

我喜欢用大小写变化来区分字段和属性：

// A private field
private Boolean someValue;
// A public property, exposing my private field
public Boolean SomeValue {
    get { return someValue; }
    set { someValue = value; }
}

【讨论】：

【解决方案6】：

也许这可以帮助你：.net Naming Conventions and Programming Standards - Best Practices

根据这个文档，是可以的。

【讨论】：

由于业务 im @ 使用 _ 来表示类的私有字段，因此不使用它不是问题。无论如何，这个问题被回答为使用 _ 是一种命名约定，即使它没有被您链接的文档所推荐。
值得注意的是，您可能会在 Internet 上找到一些文档，宣传您想要使用的任何样式......没有迹象表明任何特定文档的关注度有多高是。
在private 成员上使用前导下划线的主要原因是避免与public 访问器发生命名冲突。
对于它的价值，我曾经反对整个下划线的事情。我认为小写和大写可以很好地区分属性和变量。直到我不断遇到构造函数参数并且您想将该参数分配给私有字段。 private object something; public Ctor(object something){ this.something = something;}。如您所见，它确实有效，但您必须每次都指定 this 关键字。对私有字段使用 _something 表示法会更有意义。
@EricLiprandi ...直到您尝试在该代码上运行 StyleCop。

【解决方案7】：

有许多准则和标准可供选择，但如果您的工作场所使用的标准使用下划线，那么这就是您需要使用的。特别是如果你只是在那里实习，目标应该是保持事情的一致性（在该业务中），而不是遵循一些“更好”（但不同）的标准。

也许问你的开发人员（或更高级别的老板）更好的问题是他们是否有任何关于他们使用的标准的文档/链接？

【讨论】：

+1。我认为任何加入项目的开发人员都应该在加入项目的早期尝试掌握标准。

【解决方案8】：

人们遵循许多命名约定

myFirstVar = Camel Notation

骆驼记法一般用于公共变量（不是私有变量）。

MyFirstVar = Pascal Notation

Pascal 通常用于命名类和方法。

str_MyFirstVar = Hungarian Notation // if variable is of type string

匈牙利表示法被认为是最古老的但已不再使用。

_myFirstVariable = used for private fields in general

【讨论】：

Pascal 也用于公共属性，因为它们在技术上是伪装的方法。公共成员变量通常不应该被使用，因为它们束缚了你的手。

【解决方案9】：

这在我的经验中是比较常见的。为了帮助识别特定类型的变量（私有、方法参数等），开发人员可以使用不同的命名条件。

例如

变量名
变量名（驼峰式）
_变量
VARIABLE_NAME

我认为这往往因公司而异。

【讨论】：

或者在我工作过的几家公司中，按组或按人 :) 顺便说一句，我认为第一个称为 PascalCase，而第二个称为 camelCase（前面短，驼峰中间——像骆驼）。
是的，实际上你就在那儿，谢谢（在帕斯卡/骆驼的情况下）

【解决方案10】：

_name 杂乱无章，令人困惑且非常老式。不要这样做。

.NET 4.0 通用命名约定 http://msdn.microsoft.com/en-us/library/ms229045.aspx

如您所见，MSDN 声明

请勿使用下划线、连字符或任何其他非字母数字字符

【讨论】：

+1;虽然我同意你的观点，并且就像你的参考一样，但这个特殊案例有点像一场圣战。在争议中，产生的热量多于光......
对我来说，这是一个懒惰的问题：如果我的代码可以“告诉”读者它做了什么，我就不必 :) 下划线和前缀在某些时候一定会被我误解
反对者至少可以发表评论，明确说明他们为什么不同意微软本身
-1 并非每个团队都使用 Microsoft 命名约定。开发人员不应该更改现有代码的命名约定，因为他们更喜欢不同的命名约定。此外，只是混合使用 java（我怀疑它们是）约定和 MS 约定之类的约定会使代码更加混乱。
-1。这个微软约定没有说明private 成员。此约定仅与外部可见成员相关（如 this comment 中所述）。 OP 问题是关于 private 成员的。

【解决方案11】：

对于私人成员，有很多不同的约定。有些人喜欢前缀，有些人不喜欢（我个人不喜欢）。有些人喜欢区分实例变量和静态变量，有些人则不喜欢：

private string m_foo;
private static string s_foo;

我个人觉得下划线会妨碍我阅读文本 - 我坚信这取决于您阅读的方式；当我阅读时，我会默念，而多余的部分会妨碍我阅读。对于其他人来说，这显然不是问题。其他人发现局部变量和成员变量之间缺乏区别是一个问题 - 我通常会编写简短的方法，其中很明显无论如何都是什么。

更重要的是 - 如果您正在创建 API 等，当然是公开可见成员的命名（包括受保护的成员和参数名称），此时您应该查看 Microsoft guidelines。

【讨论】：

还有一个类似的样式指南页面blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx
这可能有助于保持你的类足够小（应用SRP 可以帮助）实例变量定义很少超过眨眼（或者可能是 PageUp）。建议我自己应该更频繁地接受......
@Firedragon 这是一个有趣的链接，尤其是微软在创建框架时似乎没有遵循他们自己的指导方针——它充满了 m_ 变量名
+1 优先考虑可读性（甚至超过私有类成员的样式指南）。
@ChrisS 一般命名准则仅适用于公共表面区域（公共/受保护成员）。我认为 Firedragon 链接的是 MS 中一个特定团队的内部指南，而不是一般的 MS。

【解决方案12】：

有两种常见的约定。

第一个是“用户下划线作为字段标记” 第二个是“静态字段使用s_，实例字段使用m_”

imo 这是一个宗教问题，唯一重要的是不要混淆两种风格。

这本书包含许多关于约定和设计指南的好想法

http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=sr_1_1?ie=UTF8&qid=1320395003&sr=8-1

【讨论】：