it-swarm.cn

命名约定: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。谢谢大家到目前为止的及时回答

70
poelinca

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

但是,在一个可以选择的地方,我倾向于使用下划线而不是驼峰式保护套,原因很简单:我发现该样式更易于阅读。这是一个示例:您发现哪个更具可读性?这个:

aRatherLongSymbolName

或这个:

a_rather_long_symbol_name

我发现下划线版本更容易阅读。我的大脑比在驼峰大小写中检测小写/大写边界更容易忽略下划线,尤其是当边界位于看起来与相反大小写的其他字形相似的字形之间时,或数字(I/lO/0t/I等)。例如,此布尔变量存储一个值,该值指示是否已使用适当的计划许可构建了Igloo(无疑是我们所有人的常见用例):

isIllicitIgloo

我发现此版本lot更易于阅读:

is_illicit_igloo

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

84
Simon Whitaker

我认为您应该使用平台采用的命名约定。 underscore_case在C#代码中看起来很奇怪,因为Ruby =)中的camelCase

97
Alexey Anufriyev

坦白地说,只要团队中的每个人都使用相同的方案,这并不重要。尽管从长远来看,真正的重要性是代码的可读性,但对每个人而言,机会都是比较自然的,因此每个人都遵守相同的命名规则至关重要。

20
dafmetal

根据John Isaacks的回复:

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

我决定做一些研究,发现 本文 。科学对此要说些什么?

  1. 骆驼纹的正确性概率比下划线大。 (赔率高51.5%)
  2. 平均而言,骆驼案所需时间增加了0.42秒,即延长了13.5%。
  3. 培训对样式如何影响正确性没有统计学上的显着影响。
  4. 那些接受训练更多的人会更快使用驼峰案例样式的标识符。
  5. 一种样式的训练对其他样式的查找时间产生负面影响。

在主题的 我的博客文章 中,我审查了科学论文,并得出以下结论。

只有驼峰情况的慢速((2))与编程真正相关,而忽略了其他点,因为现代IDE无关紧要以及研究中的大多数camelCase用户。讨论(以及民意测验)可以在博客文章中找到。

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

20
Steven Jeuris

复制最聪明的人

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

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

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

11
Mark Harrison

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

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

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

10
Paul Butcher

camelCase

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

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

8
AShelly

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

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

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

7
duros

取决于编程语言。

我考虑在同一船上是否使用匈牙利表示法使用此案例:

  • Python:underscore_case,无匈牙利符号
  • C++:camelCase,匈牙利表示法
6
Lionel

都!

我在CakePHP中进行了大量开发,并且以以下方式使用CamelCase或_$underscored_vars_(甚至在CakePHP Projects之外):

  1. 文件名 — _/lowercased_underscored.php_典型,但值得一提。
  2. classes — _class CamelCase extends ParentObject_。请注意,使用CamelCase时,首字母不能小写。我发现camelCase看起来真的很奇怪。
  3. 变量-_$are_variables_underscored === TRUE;_
  4. 保存实例的变量$CamelCase = new CamelCase();
  5. 数组键-_$collection['underscored_keys'];_
  6. constants-我想每个人都可以同意常量应该是_ALL_CAPS_AND_UNDERSCORED_。
  7. methods$CamelCase->foo_method_underscored();
  8. 静态方法CamelCase::just_like_regular_methods();
6
Stephen

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

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

过去,我们在Windows上使用underscore_case编写了C代码,并使用PascalCase Win32函数:

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

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

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

5
Paul Stephenson

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

喜欢

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

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

5
Kosta

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

4
Ross

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

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

myName   = 7
bobsName = 8   // :(

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

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

var intThingy = 7; // :(

int thingy = 7;    // :)

一旦拥有了正确的名字,而不仅仅是使用名称作为元数据,那么您将没有足够长的名称,无论您是否喜欢额外的按键,它都非常重要。

4
Kevin Cantu

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

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

4
Colin Goudie

有时我会使用混合: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。

4
Gauthier

对于我使用过的编程语言,例如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。因为我相信记住严格的规则会更容易,并且可以使Word边界更清晰(不幸的是,它需要拼写错误的内容,例如HTML或SQL)。与camelCase类似,使用htmlParserMethod而不是HTMLParserMethod或HTMLparserMethod。

[〜#〜] update [〜#〜]

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

在Java中,这意味着私有字段根据定义与本地变量位于不同的命名空间中,这意味着您可以跳过私有字段上的_this._。我见过以“ m”为前缀的其他格式,但是这些格式还使用camelCase作为变量名。这也使我能够区分只能由类内部访问的字段(并使其在类_object._field_x_之外发生时super清晰可见)。

2
Dandre Allison

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

接下来要做的就是为您所使用的语言流行的命名规则。我的instnace C++代码看起来与Python显然有些不同(PEP8是不错的指南)

您还可以使用不同的命名约定来引用不同的事物,就像您可能将UPPER_CASE用于常量一样(当然,这仅适用于某些语言),可以将this_style用于本地变量名称,而将camelCase用于实例/成员变量。但是,当您有selfthis之类的东西时,可能不需要这样做。

更新资料

让我们以您拥有平台Foo witch不推荐任何命名约定的情况为例,这是团队负责人选择的一种选择。您是该团队的负责人,为什么要选择camelCase或为什么选择underscore_case。

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

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

当然,在Ruby中,我确实会在每个块的末尾键入愚蠢的“ end”(而不是不缩进)而感到疲倦-但是,我确实避免输入同样愚蠢的':',Python在每个块的start处都需要,所以几乎是洗礼了:-)。其他语法差异,例如'@foo'与'self.foo',或Ruby vs Python)中的case的更高含义,与我实际上无关紧要。

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

来源

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

2
phant0m

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

2
Ed Harper

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

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

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

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

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

1
Skizz

我倾向于使用camelCase,这是愚蠢的原因,因为我在Eclipse中进行大部分开发工作(对于Java,PHP和JavaScript),以及当我 Ctrl+ 要么 Ctrl+ 通过文字,它实际上停在camelCase边界。

即:Eclipse会将myIntVariable视为3个字 Ctrl+← →通过它。

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

0
Bassam

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

0
Charles Bretana