C# 代码采用 Pascal 大小写还是 Camel 大小写？
我一直在与同事争论 Pascal 大小写（大驼峰式大小写）与小驼峰式大小写 CamelCasing。 它们习惯于从 SQL 数据库中的表名到 C# 代码中的属性命名等所有内容都采用小驼峰式大小写，但我更喜欢 Pascal 大小写，变量采用小驼峰式大小写，属性采用 Pascal 大小写：
string firstName;
public string FirstName {
...
}
但他们已经习惯了：
string _firstname;
public string firstName {
...
}
我尝试保留符合他们的“标准”，所以代码看起来是一样的，但我只是不喜欢它。
我已经看到至少 .NET 框架使用了这个约定，这就是我尝试保留我的代码的方式，例如：
System.Console.WriteLine("string")
您使用/喜欢什么以及为什么？ 如果其他人问这个问题，我很抱歉，但我搜索了但没有找到任何东西。
更新： 我给出了一个方法示例，而不是一个属性，但它是相同的。 正如我在第一段中所述，我的同事对所有内容（变量、方法、表名等）都使用 Pascal 约定。
I've been arguing with my coworkers about Pascal casing (upper camel case) vs. lower CamelCasing. They are used to lower camel casing for everything from table names in SQL databases to property naming in C# code but I like Pascal casing better, lower camel casing for variables and Pascal casing for properties:
string firstName;
public string FirstName {
...
}
But they are used to this:
string _firstname;
public string firstName {
...
}
I try to keep up with their "standard" so the code looks the same but I just don't like it.
I've seen that at least the .NET framework uses this convention and that is how I try to keep my code, e.g.:
System.Console.WriteLine("string")
What do you use/prefer and why? I'm sorry if somebody else asked this question but I searched and did not find anything.
Update:
I've given a method example and not a property but it's the same. As I stated in the first paragraph my colleagues use the Pascal convention for everything (variables, methods, table names, etc.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
我使用框架使用的内容，因为它是事实上的最佳实践。 但是，只要您公司的代码始终使用他们的风格，那么您最好还是习惯它。 如果每个开发人员都有自己的标准，那么根本就没有标准。
I use what the Framework uses, as it's the de-facto best practice. However, so long as the code in your company is consistently using their style, then you're much better off getting used to it. If every developer has their own standard, then there's no standard at all.
官方设计指南的链接可能会有所帮助。 具体来说，请阅读有关 大写样式。
从总体上看，Pascal 与 Camel 并没有那么重要，而且您不可能说服任何人只是为了更改名称的大小写而返回现有的代码库。 真正重要的是您希望在给定的代码库中保持一致。
只要你不使用匈牙利语我就很高兴。
A link to the official design guidelines might help. Specifically, read the section on Capitalization styles.
In the grand scheme of things, Pascal vs Camel doesn't matter that much and you're not likely to convince anyone to go back over an existing code base just to change the case of names. What's really important is that you want to be consistent within a given code base.
I'm just happy as long as you're not using Hungarian.
您应该看看 Microsoft 的新工具 StyleCop，用于检查 C# 源代码。
另请注意 FxCop 以检查已编译的 .网络组件。 FxCop 更关注代码功能的细节，而不是布局，但它确实有一些与公开可见名称相关的命名规则。
StyleCop 定义了一个编码标准，现在 Microsoft 正在将其推广为行业标准。 它根据标准检查 C# 源代码。
StyleCop 遵循您的 PascalCase 风格。
让人们使用 StyleCop（或任何其他相关标准）可能很困难，这是一个很大的障碍，而且 StyleCop 非常详尽。 但代码应该遵循统一的标准——个人标准总比没有好，公司标准比个人标准好，行业标准是最好的。
当项目开始时，说服人们要容易得多——团队正在组建，并且没有现有的代码需要转换。 如果代码不符合标准，您可以放置工具（FxCop、StyleCop）来破坏构建。
您应该使用语言和框架的标准 - SQL 代码应该使用 SQL 标准，C# 代码应该使用 C# 标准。
You should have a look at Microsoft's new tool, StyleCop for checking C# source code.
Also keep an eye on FxCop for checking compiled .Net assemblies. FxCop focuses more on the details of what the code does, not the layout, but it does have some naming rules related to publicly visible names.
StyleCop defines a coding standard, which is now being promoted by Microsoft as an industry standard. It checks C# source code against the standard.
StyleCop adheres to your PascalCase style.
Getting people onto StyleCop (or any other standard for that matter) can be hard, it's quite a hurdle, and StyleCop is quite exhaustive. But code should be to a uniform standard - and a personal standard is better than none, company standard is better than a personal one, and an industry standard is best of all.
It's a lot easier to convince people when a a project starts - team is being formed and there is no existing code to convert. And you can put tools (FxCop, StyleCop) in place to break the build if the code does not meet standards.
You should use the standard for the language and framework - SQL code should use SQL standards, and C# code should use C# standards.
我（和我的团队）更喜欢为类名保留首字母大写。
为什么？ 我认为 Java 标准正在传播。
I (and my team) prefer to reserve initial capitals for class names.
Why? Java standards propagating, I think.
我刚刚找到.Net 编码标准< /a>.
I just found Coding Standards for .Net.
从
.NET Framework 开发人员指南
大写约定，区分大小写：
From
.NET Framework Developer's Guide
Capitalization Conventions, Case-Sensitivity:
属性应使用 Pascal 大小写。 就变量名称而言，有些人使用 _，有些人使用 m_，有些人只使用普通的旧驼峰外壳。 我认为只要你在这里保持一致，就没有什么关系。
Pascal casing should be used for Properties. As far as varible names go, some people use _ and some poeple use m_ and some people just use plain old camel casing. I think that as long as you ae consistant here, it shouldn't matter.
我想你必须忍受你工作场所的编码标准，无论你个人多么不喜欢它。 也许将来的某一天你将能够决定自己的编码标准。
就我个人而言，我喜欢数据库对表和字段使用“fish_name”、“tank_id”等形式的名称，而数据库模型的等效代码是“fishName”和“tankID”。 当“fooName”可用时，我也不喜欢“_fooname”命名。 但我必须重申，这是主观的，不同的人会因为他们之前的经历和教育而对什么是好什么是坏有不同的看法。
I guess you have to put up with what the coding standard says for your place of work, however much you personally dislike it. Maybe one day in the future you will be able to dictate your own coding standards.
Personally I like databases to use names of the form "fish_name", "tank_id", etc for tables and fields, whereas the code equivalent of the database model would be "fishName" and "tankID". I also dislike "_fooname" naming when "fooName" is available. But I must repeat that this is subjective, and different people will have different ideas about what is good and bad due to their prior experience and education.
实际上，对此没有“标准”约定。 某处有一个 Microsoft 编辑的指南，与任何其他命名约定指南一样，肯定还有另一个指南反驳它，但这就是我所理解的“标准 C# 大小写约定”。
实际上，FxCop 将强制执行其中一些规则，但是（据我所知）它会忽略您对局部变量使用的任何拼写。
Actually, there's no "standard" convention on this. There's a Microsoft edited guideline somewhere, and as with with any other naming convention guideline, surely there's another one refuting it, but here's what I've come to understand as "standard C# casing convention".
Actually, FxCop will enforce a few of those rules, but (AFAIK) it ignores whatever spelling you use for local variables.
对于公共接口，您应该坚持使用 MS .NET 框架设计
指南：“大写约定”。
对于非暴露成员，那么您和您的同事可以达成一致。
For public interfaces you should stick with the MS .NET framework design
guidelines: "Capitalization Conventions".
For non-exposed members then whatever you and your colleagues can agree on.
不管你喜欢哪个，最重要的是，首先要遵守团队的标准。
在您想要的私有代码中，无论您将变量命名为 someVariable 还是 SomeVariable，都不会影响最终产品。
Whichever you prefer is what matters, obviously adhering to the team's standard primarily.
In private you code however you want, it doesn't affect the finished product whether you named your variable someVariable or SomeVariable.
当我退出编程的那一天 - 微软将在 C# 中将 CamelCase 作为标准。 因为我成长的逻辑有很多使用 PascalCase 的理由，不像孩子的逻辑，他们只关心更短的名称或更容易编写。
顺便说一句：CamelCasing 主要来自 C++ STD 库风格，这是继承自 C 的原生旧语言。因此 Java 继承自 C++。 但 C# - 是一种全新的语言 - 干净、美观，具有新的规则。 老一代人必须使用 Java 或 C++ 进行编程，新一代人必须使用 C# 进行编程 - 并且他们永远不应该进行交互。
考虑这个例子：
1) 帕斯卡命名法：list.Capacity.ToString();
2）驼峰命名法：list.capacity.toString();
在（1）中，我们有长期的骆驼案例！ 表示列表容量到字符串。
在（2）中我们有废话：listcapacitytoString。
我就是这样读的。 为什么驼峰命名法本身就是不合逻辑的。 我可以为 PascalCase 杀人，但永远不要碰它，任何年龄段的孩子。
Microsoft - 永远或直到他们使用 PascalCase。
The day when i quit programming - its when Microsoft will make CamelCase in C# as standard. Because my grown logic has many reasons for PascalCase, unlike kid's logic, who cares only shorter names or easier to write.
And BTW: CamelCasing comes primarily from C++ STD library style, the native old language inherited from C. So Java inherited from C++. But C# - is entirely new language - clean and beauty, with new rules. Oldfags must programm on Java or C++, new generation people must programm on C# - and they should never interact.
Consider this example:
1) PascalCase: list.Capacity.ToString();
2) CamelCase: list.capacity.toString();
In (1) we have CAMEL CASE in long TERM!!! means listCapacityToString.
In (2) we have bullshit: listcapacitytoString.
Thats how i read. And why CamelCase is illogical for itselt. I could kill for PascalCase, never touch it, kids of any age.
Microsoft - forever or until they use PascalCase.
我喜欢 Aardvark'd 项目规范中规定的编码约定
I like the coding conventions laid out in the Aardvark'd project spec
您发布的 .NET 示例是一个函数。 方法/函数采用的“标准”是 A capped Camel-Case（或 Pascal，如果你想这样称呼它）。
我尽可能坚持使用骆驼箱。 它可以让您轻松了解变量和方法之间的区别。
此外，我喜欢在局部类变量前面添加下划线。 例如：
_localVar。That example of .NET you posted was a function. The adopted "standard" for methods/functions is A capped camel-case (or Pascal, if you want to call it that).
I stick to camel case where I can. It lets you easily know the difference between a variable and a method.
Additionally, I'm a fan of sticking an underscore in front of local class variables. E.g.:
_localVar.