private const int THE_ANSWER = 42;
或者
private const int theAnswer = 42;
我个人认为对于现代 IDE,我们应该使用 camelCase,因为 ALL_CAPS 看起来很奇怪。你怎么看?
Temporary_Employee_Subscription_January_Grace_Period
,或任何指向特定业务逻辑案例中类别的非常具体属性的任何内容,那么定义的可读性是删除下划线时受影响:TemporaryEmployeeSubscriptionJanuaryGracePeriod
。对我来说,这是一种不同类型的常量,与您常见的“枚举”类型的常量不同。
推荐的命名和大小写约定是使用 PascalCasing 作为常量(Microsoft 有一个名为 StyleCop 的工具,它记录了所有首选约定并可以检查您的源代码是否合规 - 尽管它有点太 对于许多人的口味来说,肛门保持不变)。例如
private const int TheAnswer = 42;
Pascal 大小写约定也记录在 Microsoft 的 Framework Design Guidelines 中。
在视觉上,大写是要走的路。那样就很有辨识度了。为了唯一性,不留任何猜测的机会,我投票支持 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;
}
其实是
private const int TheAnswer = 42;
至少如果您查看 .NET 库,IMO 是决定命名约定的最佳方式 - 所以您的代码不会显得格格不入。
我仍然使用大写的 const 值,但这不是出于任何特定原因,而是出于习惯。
当然,它很容易立即看出某事是 const。我的问题是:我们真的需要这些信息吗?它是否以任何方式帮助我们避免错误?如果我为 const 赋值,编译器会告诉我我做了一些愚蠢的事情。
我的结论是:选择骆驼壳。也许我也会改变我的风格;-)
编辑:
IMO,闻起来有匈牙利风味的东西并不是一个真正有效的论点。问题应该始终是:它有帮助还是有害?
在某些情况下,匈牙利人会提供帮助。现在没有那么多了,但它们仍然存在。
首先,匈牙利表示法是使用前缀来显示参数的数据类型或预期用途的做法。 Microsoft 的命名约定对匈牙利表示法说不 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
微软在此还声明,如果与现有方案匹配,则可以使用 UPPERCASE。 http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx
这几乎概括了它。
Microsoft 在其文章 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 类库中的公共常量记录为字段。这里有些例子:
Int32.MaxValue
String.Empty(实际上是静态只读)
数学.PI
数学.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
字段)。
最后,据我所知,微软不提倡私有标识符的特定命名或大写约定,如问题中提供的示例所示。
把匈牙利语留给匈牙利人。
在这个例子中,我什至会省略最终的文章,然后继续
private const int Answer = 42;
是那个答案还是那个答案?
*按照 Pascal 进行的编辑严格正确,但我认为这个问题是在寻找对 life, the universe and everything 的更多答案。
The
。 :-)
我实际上倾向于在这里更喜欢 PascalCase - 但出于习惯,我对 UPPER_CASE 感到内疚......
不定期副业成功案例分享