Python中变量和函数名称的命名约定是什么？

来自C＃背景的变量和方法名称的命名约定通常为camelCase或PascalCase：

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

在Python中，我已经看到了上述内容，但也看到了使用下划线的情况：

# python example
this_is_my_variable = 'a'
def this_is_my_function():

有没有更优选的，确定的Python编码风格？

请参阅Python PEP 8：函数和变量名称：

函数名称应小写，必要时用下划线分隔单词，以提高可读性。

变量名遵循与函数名相同的约定。

仅在已经是主流样式（例如threading.py）的上下文中才允许使用blendCase，以保持向后兼容性。

《Google Python样式指南》具有以下约定：

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

大卫·Goodger（在“代码就像Pythonista” 在这里）描述了PEP 8项建议如下：

• joined_lower 用于函数，方法，属性，变量

• joined_lower或ALL_CAPS常量

• StudlyCaps 上课

• camelCase 仅符合先前的约定

正如Python代码样式指南所承认的那样，

Python库的命名约定有些混乱，因此我们永远都无法做到这一点

请注意，这仅指Python的标准库。如果他们不能得到那个一致，那么就几乎是具有很大的希望通常附着到约定所有的 Python代码，不是吗？

因此，在这里的讨论中，我可以推断出，如果在过渡到Python时继续使用变量或函数的Java或C＃命名惯例（例如清晰明确的命名规则），这并不是一个可怕的罪过。当然，请记住，最好遵守代码库/项目/团队的流行风格。正如《 Python风格指南》指出的那样，内部一致性最重要。

^{随意将我视为异端。:-)像OP一样，我也不是“ Pythonista”，无论如何也没有。}

如其他答案所示，有PEP 8，但是PEP 8只是标准库的样式指南，在其中仅作为福音。PEP 8对于其他代码段最常见的偏差之一是变量命名，尤其是方法。尽管考虑到使用mixedCase的代码量很大，但没有单一的主导风格，如果要进行严格的普查，则可能最终会得到带有mixedCase的PEP 8版本。与PEP 8几乎没有其他偏差是很常见的。

如前所述，PEP 8表示可lower_case_with_underscores用于变量，方法和函数。

我更喜欢使用lower_case_with_underscores变量以及mixedCase方法和函数使代码更明确和可读。因此，遵循Python Zen的 “显式优于隐式”和“可读性”

@JohnTESlade回答的内容更进一步。Google的python样式指南提供了一些非常简洁的建议，

避免使用的名称

• 单个字符名称（计数器或迭代器除外）
• 任何程序包/模块名称中的破折号（-）
• \__double_leading_and_trailing_underscore__ names （由Python保留）

命名约定

• “内部”是指模块内部或类中受保护或私有的内部。
• 在单个下划线（_）前面有一些支持来保护模块变量和函数（import * from中不包括）。在实例变量或方法前加双下划线（__）可以有效地使变量或方法对其类具有私有性（使用名称修饰）。
• 将相关的类和顶级功能放到一个模块中。与Java不同，不需要将自己限制为每个模块一个类。
• 使用CapWords类的名字，但lower_with_under.py对模块名称。尽管有许多命名的现有模块CapWords.py，但现在不建议这样做，因为当碰巧以一个类命名该模块时会造成混淆。（“等待-我写import StringIO还是写from StringIO import StringIO？”）

源自Guido建议的指南

大多数python的人都喜欢使用下划线，但是自从5年前以来，即使我使用python，我仍然不喜欢它们。它们对我来说看起来很难看，但也许这就是我脑海中的所有Java。

我只是喜欢驼峰更好，因为它适合与类的命名方式更好，感觉更符合逻辑具有SomeClass.doSomething()比SomeClass.do_something()。如果您在python中查看全局模块索引，则会发现这两者，这是因为它是随着时间的推移而增长的各种来源的库的集合，而不是由像Sun这样的公司开发的具有严格编码规则的库。我要说的底线是：使用任何您喜欢的更好的东西，这只是个人品味的问题。

我个人尝试将CamelCase用于类，mixedCase方法和函数。变量通常用下划线分隔（当我记得时）。这样一来，我就可以一目了然地告诉我我到底在叫什么，而不是所有看起来都一样的东西。

有一篇关于此的论文：http : //www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR它说snake_case比camelCase更具可读性。这就是为什么现代语言在任何可能的地方使用（或应该使用）蛇的原因。

编码风格通常是组织内部政策/惯例标准的一部分，但我认为一般来说，all_lower_case_underscore_separator风格（也称为snake_case）在python中最为常见。

在以其他编程语言进行开发时，我个人使用Java的命名约定，因为它一致且易于遵循。这样，我就不会一直在努力使用哪些约定不应该成为我项目中最难的部分！

通常，遵循语言标准库中使用的约定。