I've heard it stated in other contexts that words_with_underscores are easier to separate for non-native English readers than are wordByCamelCase. Visually it requires less effort to parse the separate, foreign words.
One reason could be historically, many computers did not have mixed case capabilities. In the days of COBOL, programs were all upper case. In the early 80's many 'personal computers' only came with upper case fonts. For example, you could get a lower case extender card for the Apple II+. When programs began allowing for mixed case, camel case was not popular. Many programs took what used to be in all caps, and just converted to lower case. Through the 80's various languages attributed meaning to case, and in the 90's Java popularized the camelCase syntax. Languages which have an older history, or are tied more closely to unix system programming tend to avoid making semantic use of mixed case.
If they agree that the existing convention is dorky (or they don't have a standard), and don't mind a little work cleaning up all of the code to a new and improved (more standard) convention, then you can do that.
Whatever you do, I think it is important that you are consistent. I have seen a couple of style guides (for example Google Python Style Guide), that tell you to use underscores.
I personally think, using lowercase letters with underscores makes the code easier to read.
You use camelCasing? I don't mind! There is always Glasses Mode. :)
Was it Meyers who came up with aLongAndTotallyUnreadableMethodeName vs an_even_longer_but_perfectly_readable_method_name comparison?
If you are already used to one, then your favorite convention will look more natural. But new programmers may prefer underscores (sample size N = me, in the year 2001).
I think some languages use camelCase because their API can be really horrible. You need the extra space so the code can fit in the IDE without wrapping.
Feel free to do whatever suits you best, but consider using one of the popular conventions. It makes it easier for other developers to get up to speed with your code.
Remember that over the life of the project, more time is spent reading the code than it takes to write it.
camelCase and/or CamelCase (and that's a debate in its own right;-) may be overwhelmingly most popular for the kind of environments you are most familiar with, but that hardly makes them universal -- or have you never heard of the obscure language called C++, with its std::find_first_of and std::replace_copy_if algorithms and so on?!
So there's no "deviation", as you state, in PEP 8 -- simply a choice towards the C++-standard conventions against the ones more popular in, say, Java or C#.
As for what you should do for your own code, just pick a convention and stick with it -- consistency's more important than other considerations. My employer uses a CamelCase convention across all languages for all internal sources (though not necessarily when it comes to exposing public APIs, which is a separate issue), I personally detest it (I wish I could destroy every reliance on case sensitivity across the programming universe!-), but I stick to it, and actually help enforce it (in code reviews), because uniformity is important.
I guess you'll understand why relying on case sensitivity is a horrible idea only if and when you have to rely on a screen reader to read code out to you -- most screen readers do a horrible job at pinpointing case issues, and there's no really good way, no strong or easy convention to convert case differences to easy auditory clues (while translating underscores to "clicks", in a good configurable screen reader, makes it a breeze). For people without any visual impairments whatsoever, which is no doubt 90% or more, you don't need to care (unless you want to be inclusive and help people who don't share your gift of perfect vision... naah, who cares about those guys, right?!).
But, consistency is still important, and helps _every_body.
发布评论
评论（10）
小写字母和下划线比较优越，因为您通常在书籍或新闻报纸中阅读的文本不是这样写的。 。
LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYouNormallyReadInABookOrNewsPaperForExampleIsNotWrittenLikeThis. .
我听说在其他上下文中说过，对于非英语母语读者来说，words_with_underscores 比 wordByCamelCase 更容易区分。从视觉上看，解析单独的外来词需要更少的努力。
I've heard it stated in other contexts that words_with_underscores are easier to separate for non-native English readers than are wordByCamelCase. Visually it requires less effort to parse the separate, foreign words.
原因之一可能是历史上许多计算机不具备混合大小写功能。在COBOL时代，程序都是大写的。在 80 年代初，许多“个人计算机”仅配备大写字体。例如，您可以获得 Apple II+ 的小写扩展卡。当程序开始允许混合大小写时，驼峰式大小写并不流行。许多程序采用了以前全部大写的内容，只是转换为小写。 80 年代各种语言都赋予大小写意义，90 年代 Java 普及了驼峰命名语法。历史悠久或与 UNIX 系统编程联系更紧密的语言往往会避免在语义上使用混合大小写。
One reason could be historically, many computers did not have mixed case capabilities. In the days of COBOL, programs were all upper case. In the early 80's many 'personal computers' only came with upper case fonts. For example, you could get a lower case extender card for the Apple II+. When programs began allowing for mixed case, camel case was not popular. Many programs took what used to be in all caps, and just converted to lower case. Through the 80's various languages attributed meaning to case, and in the 90's Java popularized the camelCase syntax. Languages which have an older history, or are tied more closely to unix system programming tend to avoid making semantic use of mixed case.
带下划线的小写字母约定可以追溯到 unix api。他们的整个系统调用都在这个约定中。
The lower case with underscores convention goes all the way back to unix apis. Their entire syscall are in this convention.
这只是一种约定，但如果您使用大量缩写，那么它会很有用。
你是如何编写EmailConfig的（或者它本来就是EMailConfig）？ HTTP 请求？ email_config 和 http_request 是更清晰的约定。
It is just a convention, but a useful one if you work with a lot of abbreviations.
How did you write EmailConfig (or was it EMailConfig)? HTTPRequest? email_config and http_request are then much clearer convention.
使用您商店使用的命名约定。
如果他们同意现有约定很愚蠢（或者他们没有标准），并且不介意将所有代码清理为新的和改进的（更标准）约定，那么你可以这样做。
Use the naming convention that your shop uses.
If they agree that the existing convention is dorky (or they don't have a standard), and don't mind a little work cleaning up all of the code to a new and improved (more standard) convention, then you can do that.
无论你做什么，我认为保持一致很重要。我看过一些风格指南（例如 Google Python 风格指南< /a>)，告诉您使用下划线。
我个人认为，使用小写字母加下划线可以让代码更容易阅读。
你用camelCasing吗？我不介意！总有眼镜模式。 :)
Whatever you do, I think it is important that you are consistent. I have seen a couple of style guides (for example Google Python Style Guide), that tell you to use underscores.
I personally think, using lowercase letters with underscores makes the code easier to read.
You use camelCasing? I don't mind! There is always Glasses Mode. :)
是 Meyers 提出了 aLongAndTotallyUnreadedMethodeName 与 an_even_longer_but_perfectly_sensitive_method_name 比较吗？
如果您已经习惯了其中一种，那么您最喜欢的惯例会看起来更自然。但新程序员可能更喜欢下划线（样本大小 N = 我，2001 年）。
我认为有些语言使用驼峰命名法是因为它们的 API 非常糟糕。您需要额外的空间，以便代码可以容纳在 IDE 中而不需要换行。
例如：
Was it Meyers who came up with aLongAndTotallyUnreadableMethodeName vs an_even_longer_but_perfectly_readable_method_name comparison?
If you are already used to one, then your favorite convention will look more natural. But new programmers may prefer underscores (sample size N = me, in the year 2001).
I think some languages use camelCase because their API can be really horrible. You need the extra space so the code can fit in the IDE without wrapping.
For example:
随意做任何最适合您的事情，但请考虑使用流行的约定之一。它使其他开发人员可以更轻松地跟上您的代码。
请记住，在项目的整个生命周期中，阅读代码所花费的时间比编写代码所花费的时间要多。
Feel free to do whatever suits you best, but consider using one of the popular conventions. It makes it easier for other developers to get up to speed with your code.
Remember that over the life of the project, more time is spent reading the code than it takes to write it.
camelCase和/或CamelCase（这本身就是一个争论；-）对于您所在的环境类型来说可能是最受欢迎的最熟悉的，但这很难使它们具有通用性 - 或者您从未听说过名为 C++ 的晦涩语言及其std::find_first_of和std::replace_copy_if算法等等？！因此，正如您所说，PEP 8 中不存在“偏差”——只是选择 C++ 标准约定，而不是 Java 或 C# 中更流行的约定。
至于你应该对自己的代码做什么，只需选择一个约定并坚持下去——一致性比其他考虑因素更重要。我的雇主在所有语言中对所有内部源使用
CamelCase约定（尽管不一定在公开公共 API 时，这是一个单独的问题），我个人讨厌它（我希望我可以销毁 < em>在整个编程世界中，每一个都依赖于区分大小写！-)，但我坚持这样做，并且实际上帮助强制执行它（在代码审查中），因为一致性很很重要。我想，只有当您必须依靠屏幕阅读器向您朗读代码时，您才会明白为什么依赖区分大小写是一个可怕的想法——大多数屏幕阅读器在查明大小写问题方面做得很糟糕，而且没有非常好的方法，没有强大或简单的约定将大小写差异转换为简单的听觉线索（同时将下划线翻译为“点击”，在一个良好的可配置屏幕阅读器中，使其变得轻而易举）。对于没有任何视觉障碍的人（毫无疑问是 90% 或更多），你不需要关心（除非你想包容并帮助那些不分享你完美天赋的人）愿景...不，谁关心那些家伙，对吧？！）。
但是，一致性仍然很重要，并且对每个人都有帮助。
camelCaseand/orCamelCase(and that's a debate in its own right;-) may be overwhelmingly most popular for the kind of environments you are most familiar with, but that hardly makes them universal -- or have you never heard of the obscure language called C++, with itsstd::find_first_ofandstd::replace_copy_ifalgorithms and so on?!So there's no "deviation", as you state, in PEP 8 -- simply a choice towards the C++-standard conventions against the ones more popular in, say, Java or C#.
As for what you should do for your own code, just pick a convention and stick with it -- consistency's more important than other considerations. My employer uses a
CamelCaseconvention across all languages for all internal sources (though not necessarily when it comes to exposing public APIs, which is a separate issue), I personally detest it (I wish I could destroy every reliance on case sensitivity across the programming universe!-), but I stick to it, and actually help enforce it (in code reviews), because uniformity is important.I guess you'll understand why relying on case sensitivity is a horrible idea only if and when you have to rely on a screen reader to read code out to you -- most screen readers do a horrible job at pinpointing case issues, and there's no really good way, no strong or easy convention to convert case differences to easy auditory clues (while translating underscores to "clicks", in a good configurable screen reader, makes it a breeze). For people without any visual impairments whatsoever, which is no doubt 90% or more, you don't need to care (unless you want to be inclusive and help people who don't share your gift of perfect vision... naah, who cares about those guys, right?!).
But, consistency is still important, and helps _every_body.