为什么我们有lower_case_with_underscores命名约定？

Question

为什么我们有lower_case_with_underscores命名约定？

dav*_*dav 19 python camelcasing pep8 naming-conventions

根据你的解释,这可能是也可能不是一个修辞问题,但它真的让我感到困惑.这个惯例有什么意义？我理解命名约定不一定要有背后的押韵或理由,但为什么偏离已经流行的camelCase？我不知道有什么押韵和背后的原因lower_case_with_underscores吗？(是的,我完整地阅读了PEP 8,是的,我确实理解它只是一个提案,指南等)

我想我的真正问题是:我正在编写一个Python库.事实上,运气好的话,相对于我的其他项目,它可能是一个相当大的库.我已经尝试尽可能地遵守PEP 8,到目前为止,我甚至保持lower_case_with_underscoresPEP 8指示功能和方法名称.但是我不得不记得使用camelCase for Twisted,camelCase logging以及其他所有东西.我应该使用什么命名约定,为什么？

令人惊讶的是,我非常关心命名,足以写出一个冗长的问题,而且我也很惊讶.也许在这些事情上我有一点强迫症.我没有太多关于它的"个人意见",因为我倾向于选择最常用的东西,在这种情况下,将是camelCase - 但它让我更加恼火的是找到那个我可能正在打破一些关于明确与隐含的永恒定律以及用石头或其他东西写成的蟒蛇的禅.

Answer 1

Ale*_*lli 49

camelCase和/或CamelCase(这本身就是一场辩论;-)对于你最熟悉的环境来说可能是最受欢迎的,但这几乎不会使它们具有普遍性 - 或者你从未听说过一种名为C++的晦涩语言,用它std::find_first_of和std::replace_copy_if算法等等？!

因此,正如您在PEP 8中所说的那样,没有"偏差" - 仅仅是对C++的选择 - 对比那些在Java或C#中更受欢迎的惯例.

至于你应该为自己的代码做些什么,只需选择一个约定并坚持下去 - 一致性比其他考虑因素更重要.我的雇主CamelCase为所有内部资源使用所有语言的约定(虽然不一定涉及暴露公共API,这是一个单独的问题),我个人厌恶它(我希望我能破坏整个编程领域对案例敏感性的所有依赖) ! - ),但我坚持,实际上有助于强制执行(在代码审查中),因为一致性很重要.

我想你会理解为什么只有当你不得不依赖屏幕阅读器向你读代码时,依赖于区分大小写才是一个可怕的想法 - 大多数屏幕阅读器在查明案例问题上做了很糟糕的工作,而且没有非常好的方式,没有强大或简单的约定将案例差异转换为简单的听觉线索(在将下划线转换为"点击"时,在一个良好的可配置屏幕阅读器中,使它变得轻而易举).对于没有任何视觉障碍的人,毫无疑问是90%或更多,你不需要关心(除非你想要包容并帮助那些不分享你完美视力的人... naah,who关心那些家伙,对吧？!).

但是,一致性仍然很重要,并且有助于_every_body.

哇!我之前从未将命名约定视为可访问性问题.+1只是为了打开我的眼睛. (12认同)
@gotgenes,tx - 大约在同一时间,其他人匿名评判它...我猜有些人不喜欢**,因为提醒不是每个人都有完美的视力,所以,提到那个一点点细节也会吸引下来投票(在封面和匿名保护下,当然,匿名懦夫很高兴这样;-).但是,即使让一个**像你这样的好人(一个_cares_并且只是不知道这个问题)现在意识到并且可能在将来考虑这个问题,这非常值得我的方式付诸行动! (3认同)
我同意，我以前从未考虑过可访问性问题。感谢您启发我（我们）。 (2认同)
显然，针对camelCase 与 under_score 的主题进行了[眼球追踪研究](http://bit.ly/1byZSic)。“尽管在准确性方面，标识符样式之间没有发现差异，但结果表明，下划线样式在时间上有显着改善，并且视觉工作量更低……随着经验或培训，样式之间的性能差异会减少。” 但并未考虑可访问性。 (2认同)

Answer 2

Ry4*_*ase 15

我听说在其他情况下,word_with_underscores比非本地英语读者更容易分开,而不是wordByCamelCase.在视觉上,它需要较少的努力来解析单独的外来词.

嗯 - 我想我比第一个解析第一个更快.不过,我是英语母语人士. (3认同)

Answer 3

smc*_*ron 12

LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYouNormallyReadInABookOrNewsPaperForExampleIsNotWrittenLikeThis..

@Scott:你的评论*更容易阅读. (48认同)
but_its_not_written_like_this_either_so_I_dont_see_your_point (15认同)
@Steve,你的评论是最容易读出所有评论的评论 (4认同)
i.think.this.is.superior.though.since.the.dot.easy.to.type.but.i.dont.看看它不能是空格的原因() { ... } 我认为很快在这个领域有很多选择。 (2认同)

Answer 4

bri*_*gge 6

一个原因可能是历史上,许多计算机没有混合的案例功能.在COBOL时代,程序都是大写的.在80年代早期,许多"个人电脑"只带有大写字体.例如,您可以获得Apple II +的小写扩展卡.当程序开始允许混合案例时,骆驼案不受欢迎.许多程序采用了以前的全部大写,只是转换为小写.通过80年代的各种语言归结为案例意义,并在90年代Java中推广了camelCase语法.具有较早历史或与unix系统编程更紧密联系的语言往往避免对混合大小写进行语义使用.

Answer 5

Ami*_*shk 5

带有下划线约定的小写一直回到unix apis.他们的整个系统都在这个惯例中.

它更进一步--Lisp允许标识符中的连字符,并且Lisps中的多个单词函数名称用连字符分隔,就像现代语言使用下划线一样.我要说这至少是相同的概念(使用替换字符,因为不允许使用空格). (3认同)

归档时间：	16 年，2 月前
查看次数：	5546 次
最近记录：	14 年，3 月前