常量的 C# 命名约定？答案

【问题标题】：C# naming convention for constants?常量的 C# 命名约定？
【发布时间】：2010-09-19 13:02:11
【问题描述】：

private const int THE_ANSWER = 42;

或

private const int theAnswer = 42;

我个人认为对于现代 IDE，我们应该使用 camelCase，因为 ALL_CAPS 看起来很奇怪。你怎么看？

【问题讨论】：

@mmiika：这个例子中的“the”是什么意思？是像“银河系漫游指南”中那样，还是从某些 C++ 编码标准继承而来？（例如，用于 Macintosh 的旧 C++ 框架 THINK C [以及后来的 Symantec C++] 使用前缀“its”表示指针/引用成员，“the”表示标量成员。）
@Peter，由于常量的值为 42，我坚信这是对 The Hitchhiker's Guide to the Galaxy 的引用。
@PeterMortensen 这很有创意！但 itsEmployee 和 itsCostumer 之类的名称听起来可能具有误导性。
MSDN：大写约定msdn.microsoft.com/en-us/library/vstudio/ms229043(v=vs.90).aspx
这里答案的问题是示例是一个/两个单词的变量。但是，当您遇到应用程序范围内使用的值的非常具体的定义时，例如Temporary_Employee_Subscription_January_Grace_Period，或任何指向特定业务逻辑案例中类别的非常具体属性的任何内容，那么定义的可读性是删除下划线时受影响：TemporaryEmployeeSubscriptionJanuaryGracePeriod。对我来说，这是一种独特类型的常量，与常见的“枚举”类型的常量不同。

标签： c# naming-conventions constants

【解决方案1】：

推荐的命名和大小写约定是使用PascalCasing 表示常量（Microsoft 有一个名为StyleCop 的工具，它记录了所有首选约定，并且可以检查您的源代码是否合规——尽管它也有点对许多人的口味来说是非常保守的）。例如

private const int TheAnswer = 42;

Pascal 大小写约定也记录在 Microsoft 的 Framework Design Guidelines 中。

【讨论】：

实际上，StyleCop 不是“微软的产品”，而是“由一位非常热情的微软开发人员开发的工具（在晚上和周末）。” （有关详细信息，请参阅 blogs.msdn.com/sourceanalysis/archive/2008/07/20/… 和 blogs.msdn.com/bharry/archive/2008/07/19/…。）话虽如此，Microsoft 的框架命名约定使用 Pascal 大小写来表示常量，因此该工具只是强制执行 Microsoft 确实发布和认可的标准.
@bdukes - 我没有说它是 Microsoft 产品，但它确实在整个组织中得到了相当多的使用和支持（作为一名前员工，我比其他任何人都早几年使用它）微软得到了它，所以我很清楚它的传统）。
我不喜欢这样，因为第一个字母通常用于指示变量是否在外部可见。在代码中，TheAnswer 看起来像一个公共属性，而不是我的私有 const。我实际上更喜欢使用 constTheAnswer 和 ConstTheAnswer 之类的前缀。
我会使用 TheAnswer 表示法，除非值为 42，在这种情况下我肯定会坚持使用 ALL_CAPS 方法。
私有字段不应该是驼峰式的，如果它是 const 的事件？

【解决方案2】：

在视觉上，大写是要走的路。那样就很有辨识度了。为了唯一性，不留任何猜测的机会，我投票给 UPPER_CASE！

const int THE_ANSWER = 42;

注意：当常量要在页面顶部的同一文件中使用并用于智能感知时，大写将很有用；然而，如果它们被移动到一个独立的类，使用大写不会有太大的区别，例如：

public static class Constant
{
    public static readonly int Cons1 = 1;
    public static readonly int coNs2 = 2;
    public static readonly int cOns3 = 3;
    public static readonly int CONS4 = 4;
}

// Call constants from anywhere
// Since the class has a unique and recognizable name, Upper Case might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }

【讨论】：

我也更喜欢这个，因为 Pascal 大小写很容易与属性引用混淆。
不管上述建议如何，我也更喜欢 UPPER_CASE 常量，因为与其他任何情况相比，它更容易识别。
@usefulBee "SNAKE_CASE" 在 C# 中强烈反对；这个答案是错误的。 C# 中 const 的正确大小写是“TitleCase”。
@BrainSlugs83，我认为这里没有对错；它归结为偏好以及使代码更清晰的原因。
@usefulBee 同意。但是，标记一下 consensus 的编写方式仍然很好。我最近一直在做大量的 Ruby 代码，我认为 SCREAMING_SNAKE_CASE 是有道理的：很明显它很特别，你甚至不需要悬停/转到定义来找出它的含义。你马上就知道了。

【解决方案3】：

其实是

private const int TheAnswer = 42;

至少如果您查看 .NET 库，IMO 是决定命名约定的最佳方式 - 所以您的代码不会显得格格不入。

【讨论】：

【解决方案4】：

我仍然使用大写的 const 值，但这不是出于任何特定原因，而是出于习惯。

当然，它很容易立即看出某事是 const。我的问题是：我们真的需要这些信息吗？它是否以任何方式帮助我们避免错误？如果我为 const 赋值，编译器会告诉我我做了一些愚蠢的事情。

我的结论：选择驼色外壳。也许我也会改变我的风格;-)

编辑：

smells 匈牙利语并不是一个真正有效的论点，IMO。问题应该始终是：它有帮助还是有害？

在某些情况下，匈牙利人会提供帮助。现在没有那么多了，但它们仍然存在。

【讨论】：

阅读代码的频率远高于编写代码的频率。当然，当您编写代码时，编译器会阻止您分配给常量。但是两年后必须维护您的代码的人呢？能够立即识别常量确实很棒。
当今的 IDE 在编译之前会发现很多问题。我认为通过名称识别常量并不重要，否则您不应该为只读变量添加一些特殊名称吗？
如果你仔细想想，大写的习惯可能来自预处理器宏而不是常量（我从未使用块大写来表示真正的常量）。在这种情况下，将宏与实际代码区分开来是有意义的，因为宏实际上很可能是一个表达式而不是一个常量值，它的扩展可能会导致副作用等等。因此，您需要知道何时使用宏以及何时使用 const。我个人很高兴看到预处理器宏的背面，它们有很大的潜力使代码难以阅读。
@Tim：我同意，最终预处理器宏带来的弊大于利。我最喜欢的 PP 宏：“#DEFINE Private Public”;-)
@Tim：C++ 标准模板库采用了小写的常量，例如std::string::npos (cplusplus.com/reference/string/string/npos)。所以 ALL_CAPS 仅适用于宏和预处理器指令——这使得它在 C# 中看起来更加愚蠢。

【解决方案5】：

首先，匈牙利表示法是使用前缀来显示参数的数据类型或预期用途的做法。微软的命名约定对匈牙利表示法说不 http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

不鼓励使用 UPPERCASE，如下所述： Pascal Case 是可接受的约定和 SCREAMING CAPS。 http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft 还在此处声明，如果与现有方案匹配，则可以使用 UPPERCASE。 http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

这几乎概括了它。

【讨论】：

是的，匈牙利表示法并非全部大写。

【解决方案6】：

微软在其文章Constants (C# Programming Guide)中给出了以下示例：

class Calendar3
{
    const int months = 12;
    const int weeks = 52;
    const int days = 365;

    const double daysPerWeek = (double) days / (double) weeks;
    const double daysPerMonth = (double) days / (double) months;
}

因此，对于常量，似乎 Microsoft 建议使用 camelCasing。但请注意，这些常量是在本地定义的。

可以说，外部可见常量的命名更令人感兴趣。实际上，Microsoft 在 .NET 类库中将其 公共常量 记录为 fields。以下是一些示例：

Int32.MaxValue
String.Empty（实际上，static readonly）
Math.PI
Math.E

前两个是PascalCasing 的示例。第三个似乎遵循 Microsoft 的 Capitalization Conventions 的两个字母的首字母缩写词（尽管 pi 不是首字母缩写词）。第四个似乎表明，双字母缩写词的规则扩展到单字母缩写词或标识符，例如E（代表数学常数e）。

此外，在其大写约定文档中，Microsoft 非常直接地声明字段标识符应通过PascalCasing 命名，并为MessageQueue.InfiniteTimeout 和UInt32.Min 提供以下示例：

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

结论：将PascalCasing 用于公共常量（记录为const 或static readonly 字段）。

最后，据我所知，Microsoft 不提倡对 private 标识符采用特定的命名或大写约定，如问题中的示例所示。

【讨论】：

撰写该文章的开发人员显然没有遵循 Microsoft 推荐的 C# 样式约定。
这个答案指向的文章已经改变。 consts 现在是公开的并且已经被 PascalCased。鉴于这两个变化，这无助于回答私有常量应该是 PascalCased 还是 camelCased。

【解决方案7】：

把匈牙利语交给匈牙利人。

在示例中，我什至会省略最终的文章，直接选择

private const int Answer = 42;

是那个答案还是那个答案？

*按照 Pascal 进行的编辑严格正确，但我认为这个问题是在寻找更多 life, the universe and everything 的答案。

【讨论】：

在这种特定情况下，它是 the 答案。但这只是因为我非常喜欢阅读 D.Adams。
是的，但问题是什么？不要因为给我带来的不便而感到抱歉；）
啊，但既然你已经知道答案，你就不能知道问题了。它们是相互排斥的。（打赌你已经知道了 ;-)
这是对 OP 问题的正确答案。 -- 如果可以的话，我会两次支持你删除The。 :-)

【解决方案8】：

我实际上倾向于在这里更喜欢 PascalCase - 但出于习惯，我对 UPPER_CASE 感到内疚......

【讨论】：

【解决方案9】：

我相信 ALL_CAPS 取自 C 和 C++ 的工作方式。这篇文章here 解释了风格差异是如何产生的。

在 Visual Studio 等新 IDE 中，很容易识别类型、范围以及它们是否为常量，因此并非绝对必要。

FxCop 和 Microsoft StyleCop 软件将帮助您提供指导并检查您的代码，以便每个人都以相同的方式工作。

【讨论】：