22

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

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

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

4

10 回答 10

53

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

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

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

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

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

于 2009-11-16T05:02:20.953 回答
18

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

于 2009-11-16T20:45:45.713 回答
16

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

于 2009-11-16T04:55:10.803 回答
7

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

于 2009-11-16T05:18:54.843 回答
5

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

于 2009-11-16T04:55:38.307 回答
3

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

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

于 2011-09-30T12:24:50.587 回答
2

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

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

于 2009-11-16T04:54:07.757 回答
2

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

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

你用camelCasing？我不介意！总是有眼镜模式。:)

于 2009-11-16T05:02:36.217 回答
1

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

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

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

例如：

poly = geometryLibrary.polygonGenerator.createFromPointSet(myList.listContentsToPointset())
于 2009-11-16T06:08:09.510 回答
0

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

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

于 2009-11-16T05:08:36.620 回答