C# .NET 实例变量命名规范？

Question

我在一家公司实习，他们的代码中有些类的命名方式如下：

public class FlagsConfig
{
    private static FlagsConfig _instance; 
}

_instance在C#中是一种命名约定吗？

我想问开发人员，但他们今天和下周都在参加课程。

- Shogoot

---

在阅读这里的答案时需要保持审慎，遵循机构现有的代码 - 不要试图违背惯例。如果你有机会提出意见，那就去做，但不要浪费精力在琐事上，比如与现有命名约定争论（除非你与现有代码足够隔离），或者试图修改现有代码中的命名约定（除了在代码审查之前进行的修改以符合现有规范）。这样做会使你非常低效，并且在此过程中让人感到愤怒 :) - Merlyn Morgan-Graham

我认为@Shogoot没有打算改变它！他质疑它是件好事。 - Angelo

我永远无法理解为什么要在成员变量中使用下划线或一些m前缀。如果这能让你的代码更易读，那意味着你的代码质量很差，类和方法过于庞大，而且你从未听说过SRP。 - Piotr Perak

@Braveyard：匈牙利命名法不会在变量名中编码物理类型。 - Piotr Perak

我是不是这里唯一一个在转换为“justNameIt”信仰之前长期追随“_name”的人？而且，我是不是唯一一个认为微软因拥有“IType”而应被视为异类的人？ - nawfal

Answer 1

也许这可以帮助你：.net 命名规范和编程规范 - 最佳实践 根据这个文档，它是可以的。

- Manu

---

由于业务im@使用_来表示类的私有字段，因此不使用它并不是一个问题。无论如何，问题的答案都是使用_作为命名约定，即使您们提供的文档没有推荐这样做。 - Shogoot

值得注意的是，你可能可以在互联网上找到支持任何你想使用的风格的某些文档... 没有迹象表明任何特定文件被广泛采纳。 - Jon Skeet

在private成员前加上下划线的主要原因是避免与public访问器发生命名冲突。 - Simon Richter

就我个人而言，我曾经反对使用下划线来区分私有字段。我认为小写字母和大写字母足以区分属性和变量。直到我不停地遇到构造函数参数并且想要将该参数赋值给一个私有字段时，才改变了我的看法。private object something; public Ctor(object something){ this.something = something;}。如您所见，这确实可行，但是您必须在每次使用时指定 this 关键字。因此使用 _something 表示私有字段更合理。 - Eric Liprandi

@EricLiprandi... 直到你尝试在那段代码上运行 StyleCop。 - user

Answer 2

对于私有成员，有许多不同的约定。有些人喜欢使用前缀，有些人不喜欢（我个人不喜欢）。有些人喜欢区分实例变量和静态变量，而另一些人则不这样做：

private string m_foo;
private static string s_foo;

就我个人而言，当我阅读文本时，下划线会妨碍我的阅读 - 我坚信这取决于你的阅读方式；我在阅读时会发声，并且这些额外的部分会妨碍我的发声。对于其他人来说，显然不是问题。其他人发现本地变量和成员变量之间缺乏区分成为问题 - 在我通常编写明显的短方法的情况下，无论如何都能清楚地知道哪个是哪个。

更重要的是 - 特别是如果你正在创建一个API等等，公开可见成员（包括受保护的成员和参数名称）的命名，此时应该查看Microsoft指南。

- Jon Skeet

---

还有一个类似的页面，用于样式指南 http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx - Firedragon

@ChrisS 一般的命名指南只适用于公共表面区域（公共/受保护成员）。我认为Firedragon链接的是微软一个特定团队的内部指南，而不是微软整体的指南。 - CodesInChaos

你忘记了添加前缀，这对于消除VS中的智能感知非常有帮助。 - Piotr Perak

虽然微软偏爱他们所做的事情，但我不明白为什么mVariable不好而IType好 - Java做得对，只需命名它们是什么，而不是表示/注释。 - nawfal

@nawfal：我对mVariable部分不太感冒，但是我喜欢接口前缀。我发现这样做可以增加清晰度。当然，你的想法可能有所不同。 - Jon Skeet

Answer 3

_instance 在C#中是否是某种命名约定？

首先，很多人提到了命名指南。请注意，这些指南大多仅适用于类型的公共接口。像您所提到的私有成员是内部实现细节，因此受到生成它们的组织政策的约束，而不受公共元素的框架设计准则的影响。

对于许多组织来说，在私有实现细节中使用下划线前缀是常见的。我个人认为这并非必要，但有些人似乎喜欢它。

然而，重要的是，即使是针对私有实现细节，也永远不应使用两个下划线。 C＃编译器团队保留权利，在将来版本的语言中使任何以两个下划线开头的单词具有我们选择的任何含义。这是我们的“紧急出口”，以防我们真的需要添加新的非上下文保留关键字，并且真的不想破坏任何现有代码。

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

- Eric Lippert

---

这是否是未记录的 __arglist 和 TypedReference 关键词都以__开头的原因？ - configurator

Answer 4

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

http://csharpguidelines.codeplex.com/

我同意 @JonSkeet 的看法，下划线很混乱，但据我所知，这是微软的标准。他提供的文件表明您的库中不要使用下划线，但我认为那是指公共成员。

更新

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

为了尊重Skeet先生，我跟随他的链接到更深入地了解：http://msdn.microsoft.com/en-us/library/ms229012.aspx，它也指出您不应该使用下划线，但该指导仅适用于静态、受保护和公共成员，而不一定适用于私有成员。

底线：是的，这是一种通用标准，但在寻找或使用外部标准之前，请首先使用任何内部协商一致的标准。

- John Weldon

---

那个编码标准不是说私有字段不要使用下划线吗？虽然正如其他人所说，最好的方法是首先查看您团队的编码标准 :-) - Firedragon

由于业务im@使用_来表示类的私有字段，因此不使用它并不是一个问题。无论如何，问题的答案都是使用_作为命名约定，即使您们提供的文档没有推荐这样做。 - Shogoot

在这种情况下，答案是……是的。这是一种常见的命名标准。例如，它是流行的C#工具ReSharper的默认设置。 - John Weldon

你展示的后面链接说：“字段的命名指南适用于静态公共和受保护的字段。” - Jon Skeet

第一个链接中的“备忘单”非常有用。 - Otiel

Answer 5

有很多指南和标准可供选择，但如果您的工作场所使用下划线作为标准，那么您需要使用它。特别是如果您只在实习期间工作，目标应该是保持一致性（在该业务范围内），而不是遵循某个“更好”的标准（但不同）。

也许更好的问题是向您的开发人员（或高层领导）询问他们是否有任何关于他们使用的标准的文档/链接？

- Miika L.

---

+1. 我认为任何加入项目的开发人员都应该尽早获取标准。 - Firedragon

Answer 6

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

例如：

• VariableName
• variableName（驼峰式）
• _variable
• VARIABLE_NAME

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

- glosrob

---

在我工作过的一些公司中，可能会按组或个人来命名。顺便说一下，第一个被称为PascalCase，而第二个则被称为camelCase（前面短，中间有峰 - 就像骆驼）。 - Merlyn Morgan-Graham

是的，你说得对，谢谢。（关于帕斯卡/驼峰命名法） - glosrob

Answer 7

_name这种命名方式混乱、令人困惑，而且非常老式。不要使用。

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

正如您所见，MSDN指出：

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

- Alex

---

虽然我同意你的感受，也喜欢你的引用，但这个特殊情况是一场所谓的圣战。存在争议，产生更多的争吵而不是帮助解决问题。 +1 - Merlyn Morgan-Graham

对我来说，这只是懒惰的问题：如果我的代码可以“告诉”读者它在做什么，那我就不必这样做了 :) 下划线和前缀注释在某些时候很容易被误解。 - Alex

投反对票的人至少可以留下评论，清楚地说明他们为什么不同意微软本身。 - Alex

@Chad：“开发人员不能更改现有代码的命名约定，因为他们喜欢另一种约定。”如果不是开发人员的职责，我看不出是谁的职责了。或者你是指个别开发人员违反了约定？ - nicodemus13

这个 Microsoft 约定并没有涉及到 private 成员。这个约定只与外部可见的成员有关（正如此评论中所述）。OP 的问题是关于 private 成员的。 - Frédéric

Answer 8

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

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

- Otiel

Answer 9

你的同事以前是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中。

- James Lawruk

Answer 10

有两种常见的惯例。 第一种是“使用下划线作为字段标记”。 第二种是“对于静态字段使用s_，对于实例字段使用m_”。 我认为这是一个宗教性问题，唯一重要的事情是不要混淆两种风格。 这本书包含了许多关于惯例和设计指南的好思路。 http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=sr_1_1?ie=UTF8&qid=1320395003&sr=8-1

- Boas Enkler