除 Pascal 和全部大写之外的常量的 C# 命名约定
目前在我的项目中，我们使用全部大写作为常量的命名约定。我想改变它，并且我同意 Pascal Casing，但我的团队领导有一个强有力的论点，即它不会明显区分常量与属性和其他类型。
请帮助我提出任何其他建议。
结果 正如 @Paolo Tedesco 和这里的大多数人所认为的，我将坚持使用 ALL_CAPS。无论如何，我现在也没有其他选择，因为 @24x7Programmer 提供的论点无法改变我的团队领导的想法。现在我不能再争论这个小问题了。
谢谢大家的建议。
In my project currently we are using All caps as naming convention for constants. I would like to change it and I'm OK with Pascal Casing but my team lead has a strong argument that it will not visibly distinguish constant from Properties and other Types.
Please help me with any other suggestions.
RESULT
As @Paolo Tedesco and most of the people here thinks, I will stick to ALL_CAPS. Anyways I don't have other option also now as the argument provided by @24x7Programmer couldn't change my team lead's mind. Now further I can't argue on this little issue.
Thank you every one for your suggestions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
MSDN 非常清楚地规定了 C# 的命名指南。如果有新人加入您的团队，您真的愿意浪费时间向他们解释您的惯例吗？如果他们在不了解您的约定的情况下直接深入代码，您是否真的希望他们在混乱中浪费时间试图弄清楚什么是什么，并将大部分时间花在用于习惯您的约定的编码上？人们需要接受每种语言都有自己的一套约定，并认识到最佳实践就是遵守这些约定。它将为您、您的团队成员和新成员节省大量时间并减少头痛。
抱歉听起来如此夸张，但我发现命名类和成员已经够难的了。我花在考虑大写、驼峰式和帕斯卡式的时间越少越好。
MSDN sets out naming guidelines for C# quite clearly. If someone new were to come and join your team, would you really want to waste time explaining to them your conventions? If they were to dive straight into the code without knowing your conventions, would you really want them to waste time in confusion trying to muddle out what's what and spending most of their time coding used to your conventions? People need to accept that each language has it's own set of conventions and realise that the best practice is to stick to them. It'll save you, your team members and new members a lot of time and headache.
Sorry to sound so melodramatic, but I find it hard enough naming classes and members. The less time I spend thinking about upper-casing, camel-casing and pascal-casing the better.
在我们的项目中，我们通常为常量定义一个单独的类，并仅对它们使用 Pascal 命名。
所以我们引用这样的常量：
In our projects we usally define a separate class for constants and use only Pascal naming for them.
So we refere constants something like this:
有官方命名指南 .NET，大多数 .NET 开发人员都遵循它。对我来说，你需要一个比“它不会明显区分常量与属性和其他类型”更好的理由来偏离这些准则。
如果遵循它们，您的代码将看起来像 .NET 代码，而不是像使用 C# 编译器编译的 C++ 代码。
There are official Naming Guidelines for .NET, to which most .NET developers adhere. For me, you'd need a much better reason than "it will not visibly distinguish constant from Properties and other Types" to deviate from these guidelines.
If you follow them, your code will look like .NET code, rather than like C++ code that is being compiled with the C# compiler.
我个人认为 ALL_CAPS_CONSTANTS_LOOK_UGLY，但是你的团队领导说得很好，他们很容易与其他东西区分开来。
您改变惯例的目的是什么？如果这只是一种审美偏好，那么我认为你应该适应现有的约定 - 作为一名专业开发人员，如果代码不符合你的偏好，你也必须能够阅读和编写代码......
I personally think that ALL_CAPS_CONSTANTS_LOOK_UGLY, but your team leader has a good point in saying that they are easily distinguishable from everything else.
What is your point for changing the convention? If it's only an aestethical preference, then I think that you should adapt to the convention in place - as a professional developer you must be able to read and write code also if it does not conform to your preferences...
这是一个主观问题。没有确凿的证据表明全部大写是一个坏主意，所以就顺其自然吧。这种问题不值得通过战争来解决。
This is a subjective question. There isn't an iron-clad proof that all-caps is a bad idea, so just go with the flow. This kind of issue isn't worth going to war over.
为什么必须能够轻松区分常量？在 C++ 和 C 中，您希望能够轻松区分宏是有道理的，但我想不出需要这样做的任何充分理由。我曾经出于习惯而使用全部大写字母，但现在大多改为 Pascal 大小写，因为它更适合其余代码。
编辑：虽然我同意其他答案，但无论如何它都是非常主观的，所以如果你已经有了一个标准，我不能说值得改变它。
Why do you have to be able to distinguish constants easily? In C++ and C it made sense that you wanted to be able to distinguish macros easily, but I can't think of any good reason for that being needed. I used to use all upper case out of habit, but mostly changed to Pascal casing now since it fits better with the rest of the code.
Edit: Though I agree with the other answers that it's very subjective anyway, so if you've already got a standard, I can't say that it would be worth changing it.
首先决定常量名称的重要性，并让它主导惯例。考虑：
我认为可读性和含义是最重要的。数据类型有时可能很重要，但无论如何，它应该从名称中显而易见。因此，我会跳过尝试让常量脱颖而出，因为它们是常量，并使用与命名变量或属性相同的约定。
First decide what's important for constant names, and let that lead the convention. Consider:
I feel that the readability and meaning is most important. The data type can sometimes be important, but then it should be evident from the name anyway. So, I would skip trying to make constants stand out just because they are constants, and use the same convention as for naming variables or properties.