为什么我们有 lower_case_with_underscores 命名约定？ [关闭]答案

【问题标题】：For what reason do we have the lower_case_with_underscores naming convention? [closed]为什么我们有 lower_case_with_underscores 命名约定？ [关闭]
【发布时间】：2010-12-16 22:36:39
【问题描述】：

根据您的解释，这可能是也可能不是修辞问题，但这确实让我感到困惑。这个约定有什么意义？我知道命名约定不一定要有押韵或背后的原因，但为什么要偏离已经流行的驼峰命名法呢？ 是否有lower_case_with_underscores 背后的韵律和原因让我不知所措？（是的，我已经完整阅读了 PEP 8，是的，我明白这只是一个提案、指南等）

我想我真正的问题是：我正在编写一个 Python 库。事实上，如果运气好的话，相对于我的其他项目，它可能是一个相当大的库。我已经尝试尽可能地遵守 PEP 8，到目前为止，我什至将 lower_case_with_underscores 维护为 PEP 8 对函数和方法名称的指示。但是让我感到困扰的是，我必须记住将骆驼案例用于 Twisted，骆驼案例用于 logging，以及其他所有内容。 我应该使用什么命名约定，为什么？

我对命名如此关心，足以写一个冗长的问题，这可能会让人们感到惊讶，这也让我感到惊讶。也许我对这些事情有点强迫症。我对它没有太多的“个人意见”，因为我倾向于选择最常用的东西，在这种情况下，这将是 camelCase - 但它让我更恼火的是发现我可能违反了一些关于显式与隐式的永恒法则，以及用石头写成的 Python 禅宗之类的东西。

【问题讨论】：

"但是为什么要偏离已经流行的camelCase呢？"我相信 lower_case_with_underscores 比 camelCase 古老得多。此外，我个人非常厌恶任何一种 MixedCase 的 camelCase。使用您喜欢的任何约定。
使用系统匈牙利语。 :P 但说真的，它根本不会让人们感到惊讶——编码风格约定与编程的任何其他方面一样是一场宗教战争。你会发现很多关于 SO 的问题都是关于在哪里放置花括号或空格的禅宗。
匈牙利语应该如何使用鸭子打字？ :p
不是，我觉得我的讽刺很明显。 :)
无论如何，lower_case_with_underscores 是一个笨拙的名称。我相信“蛇盒”是正确的术语，FWIW。

标签： python naming-conventions camelcasing pep8

【解决方案1】：

camelCase 和/或CamelCase（这本身就是一场辩论；-）对于您最熟悉的那种环境来说可能是压倒性的最受欢迎，但这几乎不是使它们具有通用性——或者您从未听说过名为 C++ 的晦涩语言，它的 std::find_first_of 和 std::replace_copy_if 算法等等？！

因此，正如您所说，在 PEP 8 中没有“偏差”——只是选择 C++ 标准约定而不是 Java 或 C# 中更流行的约定。

至于您应该为自己的代码做什么，只需选择一个约定并坚持下去——一致性比其他考虑因素更重要。我的雇主对所有内部资源都使用了所有语言的CamelCase 约定（尽管在公开公共 API 时不一定是这样，这是一个单独的问题），我个人讨厌它（我希望我可以销毁 every em> 依赖于整个编程领域的大小写敏感！-)，但我坚持它，并且实际上帮助强制执行它（在代码审查中），因为一致性是重要的。

我想您会明白为什么仅当您必须依靠屏幕阅读器向您朗读代码时才依赖区分大小写是一个可怕的想法 - 大多数屏幕阅读器在查明案例问题方面做得很糟糕，并且没有真正好的方法，也没有强大或简单的约定可以将大小写差异转换为简单的听觉线索（同时将下划线转换为“点击”，在一个好的可配置屏幕阅读器中，让它变得轻而易举）。对于没有任何视觉障碍的人，毫无疑问是 90% 或更多，你不需要关心（除非你想包容并帮助那些不分享你完美天赋的人远见...不，谁在乎那些家伙，对吧？！）。

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

【讨论】：

哇！我以前从未将命名约定视为可访问性问题。 +1 只是为了让我大开眼界。
@gotgenes, tx -- 大约在同一时间，其他人匿名 -1 了它...我猜有些人只是不喜欢被提醒不是每个人都有完美的视力，所以，提到小细节也会吸引反对票（当然，在匿名的掩护和保护下，匿名的懦夫很乐意这样做；-)。但是，即使让一个像你这样的好人（一个关心并且只是没有意识到这个问题的人）现在意识到并可能在未来考虑这个问题，也很好值得我投反对票！
我同意这一点，我以前从未考虑过可访问性问题。感谢您启发我（我们）。
显然，eye tracking study was conducted 的主题是驼峰式与下划线。 “尽管在准确性方面没有发现标识符样式之间的差异，但结果表明下划线样式在时间上的显着改善和更低的视觉工作量......通过经验或培训，样式之间的性能差异减少了。”但没有考虑到可访问性。

【解决方案2】：

小写有下划线是优越的，因为你通常在书本或新闻纸中读到的文本不是像这样写的。 .

【讨论】：

but_its_not_written_like_this_either_so_I_dont_see_your_point
@Scott：不过，您的评论非常更易于阅读。
@Steve，您的评论是所有评论中最容易阅读的评论
i.think.this.is.superior.though.since.the.dot.easy.to.type.but.i.dont.看看它不能是空格的原因() { ... } 我认为 swift 在这方面有很多选择。

【解决方案3】：

我听说在其他情况下，对于非英语母语的读者来说，words_with_underscores 比 wordByCamelCase 更容易区分。从视觉上看，解析单独的外来词需要较少的精力。

【讨论】：

更容易的视觉分离是为编程语言Eiffel明确提到的原因。他们也有这个 underscore_separator_standard。它可能对以英语为母语的读者也有帮助:-)
无论如何都更容易阅读。概念证明：TheQuickBrownFoxJumpsOverTheLazyDog vs the_quick_brown_fox_jumps_over_the_lazy_dog。最后一个可以正常高速阅读，而大脑在尝试解码第一个替代方案时进入超慢集中模式。
嗯 - 我想我解析第一个比后者更快。不过，我的母语是英语。
@hlovdal CamelCaseVERsion 对我来说更容易阅读。阅读速度比正确的文本要慢。然而，下划线版本对我来说更难阅读。单词的形状被打破，空间被填满。 “the-quick-brown-fox-jumps-over-the-lazy-dog”很容易（但令人窒息！）阅读。我认为有两点要带走：（a）不要根据自己的看法进行概括，（b）不要使用长变量名。

【解决方案4】：

一个原因可能是从历史上看，许多计算机没有混合大小写功能。在COBOL时代，程序都是大写的。在 80 年代初期，许多“个人电脑”只带有大写字体。例如，您可以获得用于 Apple II+ 的小写扩展卡。当程序开始允许混合大小写时，驼峰式并不流行。许多程序采用了过去全部大写的内容，然后转换为小写。通过80年代各种语言赋予大小写意义，90年代Java普及了camelCase语法。历史悠久的语言，或者与 unix 系统编程联系更紧密的语言倾向于避免使用混合大小写的语义。

【讨论】：

cobol 代码看起来很神奇。我曾经看过一个同事的代码。它是如此优雅。不过，他们已经有 70 年的时间对其进行微调了。

【解决方案5】：

带有下划线约定的小写字母可以追溯到 unix apis。他们的整个系统调用都在这个约定中。

【讨论】：

它可以追溯到更远的地方——Lisp 允许在标识符中使用连字符，并且 Lisp 中的多个单词函数名称用连字符分隔，就像现代语言使用下划线一样。我想说这至少是相同的概念（使用替代字符，因为不允许使用空格）。

【解决方案6】：

这只是一种约定，但如果您使用很多缩写词，它会很有用。

您是如何编写 EmailConfig（或者是 EMailConfig）的？ HTTP请求？ email_config 和 http_request 的约定更加清晰。

【讨论】：

【解决方案7】：

使用您的商店使用的命名约定。

如果他们同意现有的约定是愚蠢的（或者他们没有标准），并且不介意将所有代码清理为新的和改进的（更标准的）约定，那么您可以的。

【讨论】：

【解决方案8】：

无论你做什么，我认为保持一致很重要。我看过一些风格指南（例如 Google Python Style Guide），它们告诉您使用下划线。

我个人认为，使用带下划线的小写字母会使代码更易于阅读。

你使用camelCasing？我不介意！总是有Glasses Mode。 :)

【讨论】：

【解决方案9】：

是 Meyers 提出了 aLongAndTotallyUnreadableMethodeName 与 an_even_longer_but_perfectly_readable_method_name 的比较？

如果您已经习惯了，那么您最喜欢的约定会看起来更自然。但新程序员可能更喜欢下划线（样本大小 N = 我，2001 年）。

我认为有些语言使用 camelCase，因为它们的 API 可能非常糟糕。您需要额外的空间，以便代码可以放入 IDE 中而无需换行。

例如：

poly = geometryLibrary.polygonGenerator.createFromPointSet(myList.listContentsToPointset())

【讨论】：

不确定示例代码是否是针对蛇案例的论据，因为它不符合得墨忒耳法则。

【解决方案10】：

随意做最适合您的事情，但请考虑使用一种流行的约定。它使其他开发人员更容易掌握您的代码。

请记住，在项目的整个生命周期中，阅读代码所花费的时间比编写代码所花费的时间要多。

【讨论】：