来自C＃背景，变量和方法名称的命名约定通常是CamelCase或Pascal Case：
// C# example string thisIsMyVariable = "a" public void ThisIsMyMethod()
在Python中，我已经看到了上面的内容，但我也看到了使用下划线：
# python example this_is_my_variable = 'a' def this_is_my_function():
Python有更优选的，明确的编码风格吗？
我个人尝试将CamelCase用于类，mixedCase方法和函数 . 变量通常是下划线（当我记得时） . 通过这种方式，我可以一目了然地告诉我究竟是在呼唤什么，而不是一切看起来都一样 .
正如Style Guide for Python Code承认的那样，
Python库的命名约定有点乱，所以我们永远不会完全一致
请注意，这仅指Python的标准库 . 如果他们不能得到那种一致性，那么几乎没有希望对所有Python代码都有一个普遍遵守的约定，是吗？
从那以及在这里的讨论中，我会推断，如果一个人继续使用例如，这是一个可怕的罪 . Java 's or C#'（明确且完善的）变量和函数的命名约定，当交叉到Python时 . 当然，请记住，最好遵守代码库/项目/团队的主流风格 . 正如Python样式指南所指出的，内部一致性最重要 .
随意将我视为异教徒 . :-)和OP一样，我不是“Pythonista”，不管怎样 .
编码风格通常是组织内部策略/约定标准的一部分，但我认为通常，all_lower_case_underscore_separator样式（也称为snake_case）在python中最常见 .
Google Python Style Guide具有以下约定：
module_name，package_name，ClassName，method_name，ExceptionName，function_name，GLOBAL_CONSTANT_NAME，global_var_name，instance_var_name，function_parameter_name，local_var_name
类似的命名方案应该应用于 CLASS_CONSTANT_NAME
CLASS_CONSTANT_NAME
David Goodger（在"Code Like a Pythonista" here中）描述了PEP 8的建议如下：
joined_lower 用于函数，方法，属性，变量
joined_lower
joined_lower 或 ALL_CAPS 表示常量
ALL_CAPS
StudlyCaps 用于课程
StudlyCaps
camelCase 仅符合已有的惯例
camelCase
正如其他答案所示，有PEP 8，但PEP 8只是标准库的样式指南，并且它仅作为福音 . PEP 8对其他代码的最常见偏差之一是变量命名，特别是对于方法 . 没有单一的主导风格，虽然考虑到使用mixedCase的代码量，如果要进行严格的人口普查，可能最终会得到一个带有mixedCase的PEP 8版本 . 与PEP 8几乎没有其他偏差，这是很常见的 .
进一步了解@JohnTESlade所回答的问题 . Google's python style guide有一些非常好的建议，
Names to Avoid
除计数器或迭代器之外的单个字符名称任何包/模块名称中的
破折号（ - ）
\__double_leading_and_trailing_underscore__ names （由Python保留）
\__double_leading_and_trailing_underscore__ names
Naming Convention
"Internal"表示模块内部或类中受保护或私有 .
前置单个下划线（_）对保护模块变量和函数（不包含在import *中）有一些支持 . 将双下划线（__）预先添加到实例变量或方法有效地使变量或方法对其类是私有的（使用名称修改） .
将相关类和顶级函数放在一个模块中 . 与Java不同，不需要将每个模块限制为一个类 .
对于类名称使用 CapWords ，对于模块名称使用 lower_with_under.py . 虽然有许多名为 CapWords.py 的现有模块，但现在不鼓励这样做，因为当模块碰巧以类命名时，它会让人感到困惑 . （“等等 - 我写了 import StringIO 还是 from StringIO import StringIO ？”）
CapWords
lower_with_under.py
CapWords.py
import StringIO
from StringIO import StringIO
Guidelines derived from Guido's Recommendations
有一篇关于此的论文：http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
TL; DR它说snake_case比camelCase更具可读性 . 这就是现代语言在任何可能的地方使用（或应该使用）蛇的原因 .
请参阅Python PEP 8 .
函数名称应为小写，必要时将单词用下划线分隔，以提高可读性 . 只有在已经成为流行风格的情境中才允许使用mixedCase
变量...
使用函数命名规则：小写，必要时用下划线分隔，以提高可读性 .
就个人而言，我偏离了这一点，因为我也更喜欢 mixedCase 而不是 lower_case 用于我自己的项目 .
mixedCase
lower_case
大多数python人喜欢下划线，但即使我现在使用python超过5年，我仍然不喜欢它们 . 他们看起来很难看，但也许这就是我头脑中的Java .
我更喜欢CamelCase，因为它更符合类的命名方式 . 感觉 SomeClass.doSomething() 比 SomeClass.do_something() 更合乎逻辑 . 如果你在python中查看全局模块索引，你会发现两者，这是因为它只是个人品味的问题 .
SomeClass.doSomething()
SomeClass.do_something()
如上所述，PEP 8表示将 lower_case_with_underscores 用于变量，方法和函数 .
lower_case_with_underscores
我更喜欢使用 lower_case_with_underscores 作为变量而 mixedCase 用于方法和函数使代码更加明确和可读 . 因此遵循Zen of Python's "explicit is better than implicit"和"Readability counts"
通常，遵循语言标准库中使用的约定 .
12 回答
我个人尝试将CamelCase用于类，mixedCase方法和函数 . 变量通常是下划线（当我记得时） . 通过这种方式，我可以一目了然地告诉我究竟是在呼唤什么，而不是一切看起来都一样 .
正如Style Guide for Python Code承认的那样，
请注意，这仅指Python的标准库 . 如果他们不能得到那种一致性，那么几乎没有希望对所有Python代码都有一个普遍遵守的约定，是吗？
从那以及在这里的讨论中，我会推断，如果一个人继续使用例如，这是一个可怕的罪 . Java 's or C#'（明确且完善的）变量和函数的命名约定，当交叉到Python时 . 当然，请记住，最好遵守代码库/项目/团队的主流风格 . 正如Python样式指南所指出的，内部一致性最重要 .
随意将我视为异教徒 . :-)和OP一样，我不是“Pythonista”，不管怎样 .
编码风格通常是组织内部策略/约定标准的一部分，但我认为通常，all_lower_case_underscore_separator样式（也称为snake_case）在python中最常见 .
Google Python Style Guide具有以下约定：
类似的命名方案应该应用于
CLASS_CONSTANT_NAMEDavid Goodger（在"Code Like a Pythonista" here中）描述了PEP 8的建议如下：
joined_lower用于函数，方法，属性，变量joined_lower或ALL_CAPS表示常量StudlyCaps用于课程camelCase仅符合已有的惯例正如其他答案所示，有PEP 8，但PEP 8只是标准库的样式指南，并且它仅作为福音 . PEP 8对其他代码的最常见偏差之一是变量命名，特别是对于方法 . 没有单一的主导风格，虽然考虑到使用mixedCase的代码量，如果要进行严格的人口普查，可能最终会得到一个带有mixedCase的PEP 8版本 . 与PEP 8几乎没有其他偏差，这是很常见的 .
进一步了解@JohnTESlade所回答的问题 . Google's python style guide有一些非常好的建议，
Names to Avoid
除计数器或迭代器之外的单个字符名称
任何包/模块名称中的
破折号（ - ）
\__double_leading_and_trailing_underscore__ names（由Python保留）Naming Convention
"Internal"表示模块内部或类中受保护或私有 .
前置单个下划线（_）对保护模块变量和函数（不包含在import *中）有一些支持 . 将双下划线（__）预先添加到实例变量或方法有效地使变量或方法对其类是私有的（使用名称修改） .
将相关类和顶级函数放在一个模块中 . 与Java不同，不需要将每个模块限制为一个类 .
对于类名称使用
CapWords，对于模块名称使用lower_with_under.py. 虽然有许多名为CapWords.py的现有模块，但现在不鼓励这样做，因为当模块碰巧以类命名时，它会让人感到困惑 . （“等等 - 我写了import StringIO还是from StringIO import StringIO？”）Guidelines derived from Guido's Recommendations
有一篇关于此的论文：http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
TL; DR它说snake_case比camelCase更具可读性 . 这就是现代语言在任何可能的地方使用（或应该使用）蛇的原因 .
请参阅Python PEP 8 .
变量...
就个人而言，我偏离了这一点，因为我也更喜欢
mixedCase而不是lower_case用于我自己的项目 .大多数python人喜欢下划线，但即使我现在使用python超过5年，我仍然不喜欢它们 . 他们看起来很难看，但也许这就是我头脑中的Java .
我更喜欢CamelCase，因为它更符合类的命名方式 . 感觉
SomeClass.doSomething()比SomeClass.do_something()更合乎逻辑 . 如果你在python中查看全局模块索引，你会发现两者，这是因为它只是个人品味的问题 .如上所述，PEP 8表示将
lower_case_with_underscores用于变量，方法和函数 .我更喜欢使用
lower_case_with_underscores作为变量而mixedCase用于方法和函数使代码更加明确和可读 . 因此遵循Zen of Python's "explicit is better than implicit"和"Readability counts"通常，遵循语言标准库中使用的约定 .