我一直在与我的同事争论Pascal套管(驼峰箱)与下部CamelCasing。它们用于降低从SQL数据库中的表名到Ccode中属性命名的所有内容的驼峰大小写，但我更喜欢Pascal大小写，对于变量使用更低的驼峰大小写，对于属性使用Pascal大小写：

string firstName;
public string FirstName {
...
}

但是他们习惯了这一点：

string _firstname;
public string firstName {
...
}

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

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

System.Console.WriteLine("string")

我们使用/偏好什么？为什么？很抱歉，如果有人问这个问题，但是我搜索了却没有找到任何东西。

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

解决方案

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

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

帕斯卡套管应用于属性。就可变名称而言，有些人使用_，有些人使用m_，而有些人只使用普通的旧骆驼套。我认为只要我们在这里保持一致就没关系。

我们发布的.NET示例就是一个函数。方法/函数采用的"标准"是带帽的驼峰式保护套(如果要调用的话，则为Pascal)。

我会尽量坚持骆驼的情况。它使我们轻松知道变量和方法之间的区别。

另外，我喜欢在本地类变量前面加上下划线。例如：_localVar。

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

对于公共接口，我们应该坚持使用MS .NET框架设计
准则："资本化公约"。

对于未公开的成员，我们和同事可以达成一致。

我想我们必须忍受编码标准对工作地点所说的话，但是我们个人不喜欢它。也许将来有一天，我们可以决定自己的编码标准。

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

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

按照宏伟的计划，Pascal vs Camel没什么大不了的，我们也不太可能说服任何人回到现有的代码库中来更改名称的大小写。真正重要的是，我们希望在给定的代码库中保持一致。

只要我们不使用匈牙利语，我都会很高兴。

实际上，对此没有"标准"约定。某处有Microsoft编辑过的指南，与其他任何命名约定指南一样，当然还有另外一个驳斥它的指南，但这就是我所理解的"标准外壳惯例"。

• 类型名称(类，枚举)，常量和属性中的PerWordCaps。
• camel适用于非常长的局部变量和受保护/私有变量的情况
• 从来没有ALL_CAPS(好吧，仅在编译器定义中，而不在代码中)
• 似乎某些系统类对私有变量使用带下划线的名称(_name)，但我想这是来自原始编写者的背景的，因为它们大多数直接来自C ++。另外，请注意，VB.NET不区分大小写，因此，如果扩展该类，将无法访问受保护的变量。

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

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

我们应该看看Microsoft的新工具StyleCop来检查Csource代码。
还要密切注意FxCop，以检查编译的.Net程序集。 FxCop更加关注代码功能的细节，而不是布局的细节，但是它确实具有一些与公开可见的名称相关的命名规则。

StyleCop定义了一种编码标准，Microsoft现在正在将该编码标准作为行业标准进行推广。它会根据标准检查C源代码。
StyleCop遵循PascalCase样式。

让人们加入StyleCop(或者与此相关的任何其他标准)可能很困难，这是一个障碍，而且StyleCop非常详尽。但是代码应该遵循统一的标准，个人标准总比没有好，公司标准总比个人好，而行业标准才是最好的。

当一个项目启动团队正在形成并且没有要转换的现有代码时，说服人们要容易得多。如果代码不符合标准，则可以放置工具(FxCop，StyleCop)来破坏构建。

我们应该对语言和框架使用标准SQL代码应使用SQL标准，而Ccode应使用Cstandards。

从
.NET Framework开发人员指南
大写约定，区分大小写：

The capitalization guidelines exist
  solely to make identifiers easier to
  read and recognize. Casing cannot be
  used as a means of avoiding name
  collisions between library elements. 
  
  Do not assume that all programming
  languages are case-sensitive. They are
  not. Names cannot differ by case
  alone.