35

我一直在与我的同事争论 Pascal 套管（上驼峰式）与下驼峰式套管。它们用于降低所有内容的驼峰式大小写，从 SQL 数据库中的表名到 C# 代码中的属性命名，但我更喜欢 Pascal 大小写，变量的小驼峰大小写和属性的 Pascal 大小写：

string firstName;
public string FirstName {
...
}

但他们已经习惯了：

string _firstname;
public string firstName {
...
}

我试图跟上他们的“标准”，所以代码看起来一样，但我只是不喜欢它。

我已经看到至少 .NET 框架使用了这种约定，这就是我尝试保留代码的方式，例如：

System.Console.WriteLine("string")

你使用/喜欢什么，为什么？如果有人问这个问题，我很抱歉，但我搜索并没有找到任何东西。

更新： 我给出了一个方法示例，而不是一个属性，但它是一样的。正如我在第一段中所说，我的同事对所有内容（变量、方法、表名等）都使用 Pascal 约定。

4

14 回答 14

39

官方设计指南的链接可能会有所帮助。具体来说，请阅读大写样式部分。

从总体上看，Pascal 与 Camel 并没有那么重要，而且您不可能说服任何人为了更改名称的大小写而返回现有的代码库。真正重要的是您希望在给定的代码库中保持一致。

只要您不使用匈牙利语，我就很高兴。

于 2008-09-29T16:37:11.430 回答
37

我使用框架使用的东西，因为它是事实上的最佳实践。但是，只要您公司的代码始终使用他们的风格，那么您最好习惯它。如果每个开发人员都有自己的标准，那么根本就没有标准。

于 2008-09-29T16:35:27.613 回答
16

你应该看看微软的新工具StyleCop用于检查 C# 源代码。还要留意FxCop以检查已编译的 .Net 程序集。FxCop 更关注代码的作用细节，而不是布局，但它确实有一些与公开可见名称相关的命名规则。

StyleCop 定义了一个编码标准，现在微软正在将其作为行业标准进行推广。它根据标准检查 C# 源代码。StyleCop 遵循您的 PascalCase 风格。

让人们使用 StyleCop（或任何其他标准）可能很困难，这是一个相当大的障碍，而 StyleCop 非常详尽。但是代码应该是统一的标准——个人标准总比没有好，公司标准比个人标准好，行业标准是最好的。

当一个项目开始时说服人们要容易得多 - 团队正在形成并且没有现有的代码可以转换。如果代码不符合标准，您可以使用工具（FxCop、StyleCop）来中断构建。

您应该使用语言和框架的标准 - SQL 代码应该使用 SQL 标准，而 C# 代码应该使用 C# 标准。

于 2008-09-29T16:56:51.650 回答
9

对于公共接口，您应该坚持 MS .NET 框架设计指南：“大写约定”。

对于非暴露成员，那么无论您和您的同事都可以达成一致意见。

于 2008-09-29T16:35:59.217 回答
4

我（和我的团队）更喜欢为班级名称保留首字母大写。

为什么？我认为 Java 标准正在传播。

于 2008-09-29T16:33:56.463 回答
1

来自 .NET Framework Developer's Guide Capitalization Conventions，区分大小写：

大写指南的存在只是为了使标识符更易于阅读和识别。大小写不能用作避免库元素之间名称冲突的方法。

不要假设所有编程语言都区分大小写。他们不是。名称不能仅因大小写而异。

于 2009-02-14T18:37:31.817 回答
1

我刚刚找到.Net 的编码标准。

于 2011-07-27T07:30:56.660 回答
0

属性应该使用 Pascal 大小写。就变量名称而言，有些人使用_，有些人使用m_，有些人只使用普通的旧驼色套管。我认为只要您在这里保持一致，就没有关系。

于 2008-09-29T16:34:07.430 回答
0

您发布的 .NET 示例是一个函数。方法/函数采用的“标准”是 A capped camel-case（或 Pascal，如果你想这样称呼它）。

我尽可能坚持使用骆驼案。它可以让您轻松了解变量和方法之间的区别。

此外，我喜欢在局部类变量前面加上下划线。例如：_localVar。

于 2008-09-29T16:34:33.637 回答
0

我想您必须忍受编码标准对您工作地点的规定，无论您个人多么不喜欢它。也许在未来的某一天，您将能够规定自己的编码标准。

就我个人而言，我喜欢数据库对表和字段使用“fish_name”、“tank_id”等形式的名称，而数据库模型的等效代码是“fishName”和“tankID”。当“fooName”可用时，我也不喜欢“_fooname”命名。但我必须重申，这是主观的，不同的人会因为他们之前的经历和教育而对什么是好什么坏有不同的看法。

于 2008-09-29T16:36:52.633 回答
0

实际上，对此没有“标准”约定。某处有一个 Microsoft 编辑的指南，并且与任何其他命名约定指南一样，肯定还有另一个反驳它，但这就是我所理解的“标准 C# 大小写约定”。

  1. 类型名称（类、枚举）、常量和属性中的 PerWordCaps。
  2. camelCase 用于非常长的局部变量和受保护/私有变量
  3. 没有ALL_CAPS （嗯，仅在编译器定义中，但不在您的代码中）
  4. 似乎一些系统类使用下划线名称（_name）作为私有变量，但我猜这来自原始作者的背景，因为它们中的大多数直接来自 C++。此外，请注意 VB.NET 不区分大小写，因此如果您扩展类，您将无法访问受保护的变量。

实际上，FxCop会强制执行其中的一些规则，但是（AFAIK）它会忽略您对局部变量使用的任何拼写。

于 2008-09-29T16:40:11.860 回答
0

我喜欢Aardvark的项目规范中规定的编码约定

于 2008-09-29T16:46:27.960 回答
-1

你喜欢哪个才是最重要的，显然主要是遵守团队的标准。私下里，您可以随意编写代码，无论您将变量命名为 someVariable 还是 SomeVariable，它都不会影响最终产品。

于 2017-04-11T09:58:04.597 回答
-3

我退出编程的那一天——微软将 C# 中的 CamelCase 作为标准。因为我的成长逻辑对 PascalCase 有很多原因，不像孩子的逻辑，他只关心更短的名字或更容易写。

顺便说一句：CamelCasing 主要来自 C++ STD 库风格，这是继承自 C 的原生旧语言。所以 Java 继承自 C++。但是 C# - 是全新的语言 - 干净美观，有新的规则。Oldfags 必须在 Java 或 C++ 上编程，新一代人必须在 C# 上编程 - 他们永远不应该互动。

考虑这个例子： 1) PascalCase: list.Capacity.ToString(); 2）骆驼案例：list.capacity.toString();

在 (1) 中，我们有长期的 CAMEL CASE！表示 listCapacityToString。在（2）中我们有废话：listcapacitytoString。

我就是这样读的。以及为什么 CamelCase 本身不合逻辑。我可以为 PascalCase 杀人，永远不要碰它，任何年龄的孩子。

Microsoft - 永远或直到他们使用 PascalCase。

于 2013-04-10T04:38:16.147 回答