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

问题描述：

从 C# 背景来看，变量和方法的命名约定通常为 camelCase 或 PascalCase：

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

在 Python 中，我见过上述情况，但我也看到过使用 snake_case 的情况：

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

是否有更可取的、更明确的 Python 编码风格？

解决方案 1：

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

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

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

混合大小写仅在已经成为主流风格的上下文中才被允许（例如threading.py），以保持向后兼容性。

解决方案 2：

Google Python 风格指南有以下惯例：

module_name，，，，，，，，，，，。package_name​​​​​​​​​ClassName`method_nameExceptionNamefunction_nameGLOBAL_CONSTANT_NAMEglobal_var_nameinstance_var_namefunction_parameter_name`local_var_name

类似的命名方案也适用于CLASS_CONSTANT_NAME

解决方案 3：

David Goodger（在“像 Pythonista 一样编码”中）对PEP 8建议进行了如下描述：

• joined_lower对于函数、方法、属性、变量

• joined_lower或ALL_CAPS常量

• StudlyCaps用于课程

• camelCase只遵守先前存在的惯例

解决方案 4：

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

Python 库的命名约定有点混乱，所以我们永远无法完全一致

请注意，这仅指 Python 的标准库。如果它们无法保持一致，那么几乎不可能为所有Python 代码制定一个普遍遵守的约定，不是吗？

从这一点以及这里的讨论中，我推断，如果一个人在转向 Python 时继续使用 Java 或 C#（清晰且完善）的变量和函数命名约定，这并不是什么可怕的错误。当然，请记住，最好遵守代码库/项目/团队的主流风格。正如 Python 风格指南指出的那样，内部一致性最重要。

您可以随意将我视为异端者。:-) 与 OP 一样，我不是“Pythonista”，至少现在还不是。

解决方案 5：

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

我更喜欢使用lower_case_with_underscores变量和mixedCase方法和函数，这样代码更清晰、更易读。因此，遵循Python 的“显式优于隐式”和“可读性很重要”的原则

解决方案 6：

进一步了解 @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 建议的指南

解决方案 7：

正如其他答案所示，有PEP 8，但 PEP 8 只是标准库的样式指南，在其中仅被视为福音。其他代码片段中 PEP 8 最常见的偏差之一是变量命名，特别是方法。没有单一的主导风格，尽管考虑到使用混合大小写的代码量，如果进行严格的普查，最终可能会得到一个带有混合大小写的 PEP 8 版本。与 PEP 8 相比，几乎没有其他偏差是相当常见的。

解决方案 8：

大多数 Python 用户更喜欢下划线，但即使我已经使用 Python 五年多了，我仍然不喜欢它们。它们看起来很丑，但也许这就是我脑子里对 Java 的偏见。

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

解决方案 9：

我个人尝试对类、混合大小写方法和函数使用 CamelCase。变量通常用下划线分隔（如果我能记得的话）。这样我就能一眼看出我到底在调用什么，而不是所有东西看起来都一样。

解决方案 10：

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

TL;DR 它表示 snake_case 比 camelCase 更易读。这就是为什么现代语言尽可能使用（或应该使用）snake 的原因。

解决方案 11：

无论是否在课上或课外：

变量和函数都是小写的，如下所示：

name = "John"

def display(name):
    print("John")

如果它们超过一个单词，则它们用下划线“_”分隔，如下所示：

first_name = "John"

def display_first_name(first_name):
    print(first_name)

并且，如果变量是常量，则它是大写的，如下所示：

FIRST_NAME = "John"

解决方案 12：

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

解决方案 13：

列宁说过……我也是 Java/C# 世界的。还有 SQL。我仔细研究了自己，试图找到乍一看可以理解的复杂结构示例，例如列表词典中的列表，其中所有内容都是对象。对我来说 - camelCase 或其变体应该成为任何语言的标准。复杂句子应该保留下划线。

解决方案 14：

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

解决方案 15：

PEP 8 是一条指导方针，而不是法律。它是 Python 上的一个选项，而不是官方语言的一部分。如果每个人都使用相同的风格，那么在较大的公司中，这将是首选。

我家里的所有 Python 程序都使用 camelCaseNames 完美运行，除非有人能证明我的代码运行速度较慢或行为错误，否则我不会改变这一点。然而，在我的工作中，他们希望设计师遵循相同的规则，因此选择了 PEP 8 和一组附加规则。这并不意味着他们使用 autopep8，有许多工具可以符合 PEP8 规范，只需进行细微改动，例如 black、flake8、autopep8。

改进代码以符合 PEP8 的工具主要基于意见管理。因此，如果人们使用“必须有”、“应该有”、“应当有”等词，则应将其替换为“可以有”。我会询问贵公司的偏好。

除了 PEP8，我还可以推荐 pylint 和 mypy，这些工具确实可以发现代码中的问题和致命缺陷。

解决方案 16：

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