命名约定：camelCase与underscore_case？您对此有何想法？[关闭]

我已经使用了underscore_case大约2年了，由于新工作，我最近改用了camelCase（后来使用了大约2个月，后来我仍然认为underscore_case更适合涉及大量程序员的大型项目，主要是因为代码更易于阅读）。

现在，每个人都使用camelCase，因为（他们说）代码看起来更优雅。

您对camelCase或underscore_case的看法

ps请原谅我的英语不好

编辑

首先更新：

• 使用的平台是PHP（但是我不希望得到与PHP平台相关的严格答案，任何人都可以分享他们的想法，最好使用它，这就是为什么我首先来到这里）

• 我和团队中的其他人一样使用camelCase（就像你们大多数人一样推荐）

• 我们使用Zend Framework，它也推荐camelCase

一些示例（与PHP相关）：

• Codeigniter框架建议使用underscore_case，说实话，代码更易于阅读。

• ZF推荐了camelCase，但我并不是唯一一个认为ZF代码更难理解的人。

所以我的问题改写为：

让我们以您拥有一个不推荐任何命名约定的Foo平台为例，这是团队领导者选择一个的惯例。您是那个团队的负责人，为什么要选择camelCase或为什么选择underscore_case？

ps谢谢大家到目前为止的迅速回答

我同意这在某种程度上取决于您使用的语言。当您的符号名称遵循与语言的内置库和库相同的格式设置时，代码看起来会更加整洁。

但是，在一个可以选择的地方，由于一个简单的原因，我更喜欢使用下划线而不是驼峰式的情况：我发现该样式更易于阅读。这是一个示例：您发现哪个更具可读性？这个：

aRatherLongSymbolName

或这个：

a_rather_long_symbol_name

我发现下划线版本更易于阅读。我的大脑能够更容易地忽略下划线比它可以检测小写/大写边界在骆驼的情况下，尤其是在边界的字形看上去类似相反的情况下其他的字形，或数字（间I/l，O/0，t/I等等）。例如，此布尔变量存储一个值，该值指示是否已通过适当的计划许可构建了Igloo（无疑是我们所有人的常见用例）：

isIllicitIgloo

我觉得这个版本很多更容易阅读：

is_illicit_igloo

容易误读的符号名称也许比难于理解的符号名称还要糟糕。好的符号名称是自记录的，对我来说，这意味着您应该能够阅读它们并一眼理解它们的含义。（我敢肯定，我们都会在床上阅读代码打印输出，以求取乐，但有时我们也会急忙作呕。）我经常发现骆驼式的符号名称很容易误读它们，并给人以错误的印象。符号的语义。

我认为您应该使用平台采用的命名约定。underscore_case在C＃代码中看起来很奇怪，就像Ruby中的camelCase =）

坦白地说，只要团队中的每个人都使用相同的方案，这并不重要。尽管从长远来看，真正的重要性是代码的可读性，但每个人都遵循相同的命名规则至关重要。

根据John Isaacks的回复：

“老实说，代码更容易阅读”观点还是事实？

我决定进行一些研究，并找到了这篇论文。科学对此要说些什么？

1. 骆驼的正确性比下划线大。（赔率高51.5％）
2. 平均而言，骆驼案所需时间增加0.42秒，即增加13.5％。
3. 培训对样式如何影响正确性没有统计学上的显着影响。
4. 那些受过更多培训的人员会更快地识别出驼峰案例样式中的标识符。
5. 一种样式的训练会对其他样式的寻找时间产生负面影响。

在有关该主题的博客文章中，我回顾了科学论文，并得出以下结论。

只有骆驼情况 （2）的缓慢才与编程真正相关，由于现代IDE和研究中的大多数camelCase用户，因此忽略了其他要点。讨论（以及民意测验）可以在博客文章中找到。

我很好奇这篇文章如何改变人们的看法。:)

复制最聪明的人

对于编程语言，请复制该语言开发人员的样式。

例如，我完全按照K＆R中的代码编写C。

然后，当有人尝试开始无聊的编码风格对话时，我可以告诉他们“与Dennis Ritche交流，让我知道他在说什么”。

一般来说，我更喜欢camelCase。但是，因为那是我职业生涯的大部分时间，所以我一直在样式指南通常推荐camelCase的语言和环境中工作。（Java，ECMAScript，C ++）。作为PHP的人，您可能会有相反的偏好。

就是说，当您超出三个OrFourWords范围时，或者如果您使用诸如XmlForExample之类的首字母缩写，它将不再那么可读。

这就是emacs为我们提供眼镜模式的原因。

骆驼香烟盒

这是我总是会选择“类型能力”而不是可读性的少数地方之一。CamelCase键入起来更容易，并且对我的手指更友善，对我而言，可读性略胜一筹。

当然假设该项目不是建立在具有不同标准的现有代码库上。

我已经考虑了很多次，这是一个有趣的问题。但是，我认为没有确切的答案。

遵循“文化”惯例是一个不错的选择。在这种情况下，“文化”表示在团队/公司中建立的约定，并且它们基本上也包含语言/平台约定。它可以帮助其他人轻松阅读/使用您的代码，而无需花费额外的精力和时间来理解代码。

有时，打破公认的符号很有趣。我的一个小型项目（在Python上）用于underscored_names实用程序功能/“受保护”方法，而Java风格则methodNames用于方法。我的团队对此很满意:)

取决于编程语言。

我考虑在同一条船上使用是否使用匈牙利表示法的情况：

• Python：underscore_case，无匈牙利符号
• C ++：camelCase，匈牙利表示法

都！

我在CakePHP中进行了大量开发工作，并且以以下方式（甚至在CakePHP项目外部）使用CamelCase或$underscored_vars：

1. 文件名 - /lowercased_underscored.php典型，但值得一提。
2. 类 - class CamelCase extends ParentObject。请注意，使用时CamelCase，初始字符不是小写。我发现camelCase看起来真的很奇怪。
3. 变量 -$are_variables_underscored === TRUE;
4. 保存实例的变量 -$CamelCase = new CamelCase();
5. 阵列键 —$collection['underscored_keys'];
6. 常量 -我想每个人都可以同意常量应该是ALL_CAPS_AND_UNDERSCORED。
7. 方法 —$CamelCase->foo_method_underscored();
8. 静态方法 -CamelCase::just_like_regular_methods();

我个人更喜欢，underscore_case因为我发现它更具可读性，但与其他答复者一致，后者指出与现有代码库的一致性更为重要。

但是，对于那些说“遵循您的语言及其库的约定”的人，我有一个反例。

过去，我们使用编写Windows上的C代码underscore_case，并调用PascalCaseWin32函数：

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

我们的函数名与Microsoft函数名之间的视觉区别是帮助而不是障碍，因为代码清楚地表明了何时代码进入“系统领域”。

另外，我能够更改编辑器的语法突出显示规则，以不同的颜色显示它们，这在尝试理解不熟悉的代码部分（甚至我自己的代码）时提供了进一步的视觉线索。

我真的很喜欢Dylan的普通破折号，因为它们易于键入且易于阅读。

喜欢

result-code := write-buffer(file-stream, some-string)

但是我想这门语言相当晦涩，所以有点离题了... :(

我在大学里被教导要使用camelCase。在过去的几年中，我使用了一些不同的约定，但相对于其他而言，我更喜欢camelCase。我想我记得在某个地方读过camelCase实际上是最容易阅读和理解的地方。

正如大多数人提到的-使用现有标准。如果这是一个新项目，请为将要使用的语言和框架使用标准。

而且不要混淆，这与可读性（主观性）无关，而是与一致和专业有关。在具有众多“标准”的代码库中工作的任何人都会理解。

有时我会使用混合：module_FunctionName。我模块中的所有（非静态）功能均以模块缩写开头。

例如，用于在I2C总线上发送缓冲区内容的函数：

i2c_BufferSend()

替代方法i2c_buffer_send没有在前缀和函数名称之间显示足够大的距离。i2cBufferSend前缀混用太多（此模块中有很多I2C功能）。

i2c_Buffer_send 不过，可能是另一种选择。

我的回答是，您要适应最适合您的项目的内容（您的语言，软件体系结构等），我想指出的是，混合使用这些样式可能会很有用。

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase。I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why。

就个人而言，我更喜欢camelCase，但在某些字体中，我认为下划线更易于阅读。

我建议，如果需要使用前缀来区分变量集，则应使用一种语言，该语言可以创建名称空间或对象或用于保存该信息的内容。

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

同样，如果需要区分类型，为什么不使用允许它们的语言呢？

var intThingy = 7; // :(

int thingy = 7;    // :)

一旦有了直截了当的含义，而不仅仅是使用名称作为元数据，那么您将没有足够长的名称，无论您是否喜欢额外的按键，它都非常重要。

首先，我同意dafmetal。最重要的是，不要混用不同的编程样式。在同一文件中执行此操作是恕我直言的最糟糕的做法。在不同的文件中，它可以分散注意力，但不会致命。

接下来要做的就是命名一种流行的规则，这些规则在您所写的语言中很流行。我的instnace C ++代码看起来显然与Python有所不同（PEP8是不错的指南）

您还可以使用不同的命名约定来引用不同的事物，就像您可能将UPPER_CASE用于常量一样（当然，这仅适用于某些语言），可以将this_style用于本地变量名称，而将camelCase用于实例/成员变量。当你拥有的东西，如这可能是不需要的self或this然。

更新资料

让我们以一个平台Foo witch不推荐任何命名约定为例，这是团队领导者选择一个的选择。您是该团队的负责人，为什么要选择camelCase或为什么选择underscore_case。

彼此之间没有任何优势。这件事是非常主观的，一旦达成共识，就不会有所作为。关于这些小事情总是存在着宗教战争。但是一旦您适应了任何一种，讨论似乎就完全多余了。

在一个非常相似的问题上引用亚历克斯·马特利：

当然，在Ruby中，我确实会在每个块的末尾键入愚蠢的“ end”（而不是不缩进）而感到疲倦-但随后，我确实避免输入Python要求的同样愚蠢的'：' 每个块的 开始，所以几乎可以洗了：-)。其他语法差异，例如'@foo'与'self.foo'，或者Ruby vs Python中case的重要性更高，实际上与我无关。

毫无疑问，其他人正是基于这样的问题来选择编程语言，并且引发了最激烈的辩论-但对我而言，这只是帕金森法则中一个有效的例子（关于某个问题的辩论数量与该问题的辩论成反比实际重要性）。

资源

如果您是团队负责人，那您就只选一个。由于一个没有别的优势，您可以扔骰子或选择自己喜欢的东西。

几年前，我读过一些不讲英语作为第一语言的程序员倾向于发现下划线的情况更容易理解驼峰式的情况，但是我找不到参考文献，也不知道它是否正确。

对于我使用过的编程语言，例如Java，Python，C ++，我采用了一种清晰的格式：

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

这使我可以立即辨别正在处理的内容。我发现这对于自己维护很有用，其他人阅读代码应该很容易遵循。我认为，正如其他人提到的那样，一致性至关重要。因此，我发现格式很容易维护，同时在名称类型之间提供了清晰的区别。我可以想象interface_Names_Are_Like_This和Abstract_Classes_Are_Like_This是可能的扩展，但是遵循起来似乎更加复杂，也许做起来没那么有用。

我还发现严格执行并在PascalCase中命名事物很有用，例如将HTML解析器命名为HtmlParser而不是HTMLParser或HTMLparser。因为我相信记住严格的规则会更容易，并且使单词边界更清晰（不幸的是，它需要拼写错误的东西，例如HTML或SQL）。与camelCase相似，使用htmlParserMethod而不是HTMLParserMethod或HTMLparserMethod。

更新：

从那以后，我发现可以将这些规则扩展为包含私有变量。-_private_variable_names_are_prefixed_with_an_underscore-_PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

在Java中，这意味着私有字段按照定义与本地变量位于不同的命名空间中，这意味着您可以跳过this.on私有字段。我见过其他以“ m”开头的格式，但是这些格式也使用camelCase作为变量名。这也使我能够区分只应由类在内部访问的字段（并使其在类外部发生时变得非常清晰object._field_x）。

如果由我决定，我不会强制使用或暗示使用任何特定样式，因为作为程序员，我们将能够读取IfItIsInCamelCase或in_underscore_space甚至in_SomeOtherStyle符号并了解其含义。在大型方案中，不必花费很少的时间来解析符号就不会有太大的开销。

现在，我猜想一个约定的主要参数是您预先知道函数/变量名称的格式是什么，不需要查找它-是LoadXMLFile，loadXMLFile，LoadXmlFile，load_xml_file吗？现在，我将通过说“获取支持智能感知样式自动完成的IDE！”来反驳这一论点。（尽管并非总是可能的）。

最后，因为编译器/解释器并不在乎，所以使用哪种样式并不重要。重要的是该名称很有用：

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

三种不同的样式，但是您确切知道每种样式的作用。

可能看起来很傻，但是我不喜欢下划线，因为下划线很细，并且隐藏在多行文本中，我很想念它。同样，在某些（许多）文本编辑器和/或开发环境中，当您双击标记名称以突出显示以便复制或拖放标记时，系统将不会突出显示整个标记，而只会突出显示一部分标记，在相邻的下划线之间。那使我发疯。

我倾向于使用camelCase的原因很愚蠢，因为我在Eclipse中进行了大部分开发工作（对于Java，PHP和JavaScript），并且当我通过单词进行Ctrl+ ←或Ctrl+ →运算时，它实际上停留在camelCase的边界。

即：myIntVariable当Eclipse 通过Ctrl+ 时，它将被视为3个单词← →。

我知道这是一个奇怪的怪癖，但我发现自己更喜欢能够编辑camelCase名称中的中间单词。