变量命名约定？[关闭]

我刚刚开始使用ReSharper（用于C＃），我有点喜欢它的代码气味查找器，它向我展示了我很久以前就打算解决的一些内容（主要是变量命名约定）。

这使我重新考虑了一些方法和实例变量的命名约定。ReSharper建议实例变量为小写字母并以下划线开头。有一阵子，我打算让我所有的局部变量都变成小写，但是下划线是必要的吗？你觉得舒服吗？我不喜欢这个约定，但是我还没有尝试过，您对此有何看法？

促使我重新评估的第二件事是我对GUI事件处理程序的命名约定。我通常使用ControlName_Action的VS标准，而我的控件通常使用匈牙利表示法（作为后缀，以帮助在代码中阐明用户可见的内容以及在处理类似命名的变量时不可见的内容），所以我最终得到OK_btn_Click（ ），您对此有何看法？我应该屈从于ReSharper公约还是其他同样有效的选择？

您可以修改ReSharper以使用您使用的任何命名约定方案。它非常灵活，包括自定义事件处理程序，字段，属性，具有各种可访问性级别的方法等。

不要让该工具定义您的标准-请使用它来实施自己的标准。

更新： 话虽如此，在工作中，我们对大多数私人物品（变量，字段和参数）主要使用小写字母大写。方法名称，常量和属性的大写驼峰形式。事件处理程序是根据它们表示的操作命名的，而不是控件特定的名称-例如HandleCustomerContinue而不是HandleContinueButtonClick。我尝试了ReSharper默认方案一段时间了，但实际上并不介意，我对这两种方法都不感到困惑。

关于

但是下划线是必需的吗？你觉得舒服吗？

我非常喜欢使用下划线的一件事是，它大大减少了对“ this”的使用。

考虑：

public void Invoke(int size) {
    _size = size;
}

没有下划线，您将必须编写：

public void Invoke(int size) {
    this.size = size;
}

这可能会引入以下微妙的错误：

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

另外，代码完成更为简洁，因为只需打下划线，您就可以获得仅专用字段的列表，而使用“ this”，您可以获得所有内容的列表。

关于

通常使用匈牙利表示法

框架设计指南：可重用.NET库的约定，符号和模式说：

不要使用匈牙利表示法

几乎没有歧义：)

一致性确实是关键。那和明确性，即不要含糊不清或尝试通过缩写所有内容来节省键入内容。Intellisense是您的键入保护程序，而不是晦涩的名称（但简称！）。

在C＃中，以下划线开头的受保护名称或公共名称违反了通用语言规范。只有私人会员才是正确的。

从MSDN：

为了与其他对象进行完全交互，而与实现对象所使用的语言无关，对象必须仅向调用者公开与它们必须互操作的所有语言所共有的那些功能。因此，已经定义了通用语言规范（CLS），它是许多应用程序所需的一组基本语言功能。

请参阅：http：//msdn.microsoft.com/en-us/library/12a7a7h3.aspx

在这里，您可以阅读有关下划线的警告：

以下划线（_）开头的元素名称不是公共语言规范（CLS）的一部分，因此，符合CLS的代码不能使用定义此类名称的组件。但是，元素名称中任何其他位置的下划线均符合CLS。

请参阅：http : //msdn.microsoft.com/en-us/library/81ed9a62.aspx

受保护的成员是有问题的，因为您可以继承用另一种语言编写的类。

但是，如果您不需要CLS编译代码，那么也许对您而言不是问题。

我喜欢下划线。乍一看，您知道该变量是类成员并且是私有的。

当然，IDE可以告诉您，将鼠标悬停在它上面时，但是“第一眼”是无法击败的。您知道什么是局部变量，什么是成员变量。无需滚动或鼠标悬停。

您可以使用“ this”关键字，但是_较短以提高水平可扫描性。通常需要描述性名称，但是当已确定惯例时，最好使用1个字符。例如，在遍历数组时使用字母i作为索引。由于i是索引已成为惯例，因此您可以获得可扫描性的好处，而不必担心“ i”的含义。

我大体上同意别人所说的话，但是对于工具和工具链，我很懒惰，喜欢轻松的生活。他们发现，按照他们的方式生活，通常会更容易一些。原因是

• 它安装起来更容易（只需使用默认值，即使我可以按Enter键20次即可运行）
• 这些错误通常是通过默认设置解决的，通常是我设置的神秘配置，这会首次暴露出缺陷
• 工具链供应商可能比我更了解它，因此他们这样做是有原因的。我是谁来确定专家是错误的（我认为他们是专家，因为我购买了他们的工具）
• 您将永远不必为经理选择的供应商辩护-“这就是他们的建议”
• 新来的人不会用“为什么”和“这样更好”来烦您-当每个答案都是“因为他们决定...”

因此，我的看法是，如果您能找到合理的理由来重新配置刚刚花了大钱的工具，那么一定要这样做。如果您不能证明进行更改的理由，那就不要。

请记住，每项更改都有持续的维护成本（实际和隐藏）。数量越少，成本越低。例如-我提到的那个新人-没有变化意味着他可以阅读他们的手册。重新配置-您必须编写附录，将其与其他物品一起存放，撤离，并让他在阅读他们的手册后阅读。一家2人店也许不是问题，但是100人店呢？

您要询问的两个规则（在私有字段名称的开头下划线和方法名称）通常被视为C＃开发圈中的规范。通过适应这些约定，您的代码将立即被其他开发人员更容易理解，因为这是他们习惯于进行操作的心态。

控件的Label，RadioButton等后缀通常也被视为标准。通常，对于一个概念（例如，Label和TextBox），将存在多个控件，并且此后缀非常有用。真正的匈牙利符号在很早以前就被放弃了，因为它已经被混为一类，不能表达其最初的意图，即有关变量的上下文，而不是什么类型，大小等。

就我而言，使用camelcase和下划线有助于描述性（读取：长）变量名和代码完成。我不太确定Visual Studio自动补全的工作方式，但是在QtCreator中（在较小的范围内，Eclipse）可以键入，例如

sDI

并扩展到

someDescriptiveIdentifier

如果您的名字像

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

在“描述性命名模式”下，我倾向于产生这种情况。

使用下划线，我可以确定要自动完成的名字

someDescriptiveIdentifier

要么

_someDescriptiveClassMember

希望我的解释很清楚:)