PEP 8 – Style Guide for Python Code
Python 代码样式指南
作者：Guido van Rossum, Barry Warsaw, Alyssa Coghlan
译者：Number_Sir
原发布时间: 2001-07-05
原文链接：https://peps.python.org/pep-0008/
介绍
本文档将给出由 Python 主要发布版中的标准库代码使用的代码规范。至于由 C 实现的 Python 源代码中， C 程序的代码风格指南，请参见 PEP 7。
本文档与 PEP 257（注释文档规范）均由 Guido 最初的 Python 风格指南文章修改而来，并在其中融入了 Barry 的风格指南中的部分内容。
本文档确定的代码风格将随时间推移而不断发展，因为未来将有更多的规范确立，而且 Python 语言本身也将不断变化，可能使部分老旧的风格指南过时弃用。
不少项目都有着独自的代码风格指南，因此一切与本文档冲突的部分，优先参照项目自身的风格指南。
反对本本主义
Guido 的主要见解之一是：读代码总比写代码多。因此本文档将致力于提升代码的可读性，并使这一规范在整个项目中连续一致。正如 PEP 20 所说：“可读性至关重要”。
众所周知，所谓代码风格指南就是关于代码风格的“一致性”。本文档中的“一致性”很重要，一个项目中的“一致性”更重要，一个模块一个函数中的“一致性”最重要。
尽管如此，你也要知道有些时候要打破这种“一致性”——尤其是代码风格指南所述建议不适用于具体情况时。当你感到摸不着头脑时，多发挥你的辩证思维，具体情况具体分析，多参考其它的例子，对比选择最适合的方案。也不要羞于向别人提问！
具体而言就是：不要一味为了迎合 PEP 规范而不顾你代码的兼容性！
此外，在这些情况下，你完全没有必要执着于迎合特定的代码风格指南：
- 当指南让代码丧失可读性，甚至连已经习惯于遵照 PEP 阅读代码的开发者都感到困惑时
- 当遵照指南的这部分代码，其前后文并未遵照这个指南时（可能出自一些历史原因）——尽管这可能是个清理屎山的好机会（除非你是个重构癌患者）。
- 当这部分代码编写早于指南的编写时，当然没有什么特殊理由要去改这部分代码。
- 当这部分代码需要兼容旧版本的 Python 解释器，而遵照指南与兼容旧版有冲突时。
代码外观
缩进
每层缩进应为 4 个半角空格的长度。
对于圆括号()，方括号[]，花括号{}包裹的参数，换行后应与括号后一个字符对齐，或是使用“悬挂缩进”：第一行括号内不应有参数，第二行应多缩进一层，且每次换行都与第二行对齐，以便与后续内容区分：
# 正确:
# 与括号后一个字符对齐
foo = long_function_name(var_one, var_two,
var_three, var_four)
# 悬挂缩进
# 第一行括号内为空，后续行均多缩进一层
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# 悬挂缩进
foo = long_function_name(
var_one, var_two,
var_three, var_four)
# 错误：
# 第一行括号内有内容，后续行与括号内不对齐
foo = long_function_name(var_one, var_two,
var_three, var_four)
# 使用悬挂缩进，但后续行没有多缩进一层
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)对于“悬挂缩进”规则，不一定必须要 4 空格
# 本例使用 2 空格
foo = long_function_name(
var_one, var_two,
var_three, var_four)
Tab 缩进还是空格缩进？
最好用半角空格，而非 Tab（制表符）缩进。
制表符缩进最好只在那些前后文均已经大量使用制表符缩进的代码中使用。
而且 Python 并不支持混用半角空格和制表符缩进。
单行最大长度
二元运算符前换行还是二元运算符后换行
空白行
源代码编码格式
导入包
双下划线变量
字符串引号
表达式中的空格
约定俗成
其他推荐格式
什么时候在行末尾加逗号
注释
代码块注释
行内注释
文档注释
命名规范
Python 库的命名规范有点混乱，所以这部分的“一致性”有点难以落实——不过下面会列出当前建议的命名标准。至少新的模块和包（包括第三方的框架等）都应该按照此标准编写，但对于此前已经编写好的库，最好还是遵循其原有的规范。
最高准则
提供给用户使用的接口中，对于公开可见的名称，应优先按照反映其用法的规范命名，而非按照反映其实现的规范命名。
约定俗成：命名风格
规范约束：命名原则
不应使用的名称
永远不要使用小写字母哎要：l，大写字母欧：O，大写字母艾：I这几个单个字母作为变量名。
在一些字体中，这些字符容易和阿拉伯数字一：1和零: 0混淆。如果坚持要使用l，请使用大写L替代。
ASCII 兼容
在标准库中使用的标识符必须符合 ASCII 兼容性，具体参见 PEP 3131 的原则规范。
包名和模块名
模块名应该使用简短、全小写字母的名称，可以在提升可读性的前提下，适当使用下划线。包名也应该使用简短、全小写字母的名称，但是不推荐使用下划线。
对于使用 C/C++ 编写的拓展模块，如果这个模块同时与用 Python 编写的提供高级接口（如面向对象）的模块共同使用，则 C/C++ 模块的名称应该在最前面加上一个下划线（例如 _socket）。
类名
类名应该使用帕斯卡命名法（也称大驼峰命名法），如 SomeRandomClass。
如果某个类/接口一般只用于被调用的情况，并有完善的文档说明，则也可以按照函数名的规范命名。
至于 Python 内置变量的名称规范有些不同：大多数内置变量的名称都是单个单词或两个单词挤在一起，帕斯卡命名法只用于异常的命名以及内置常量的命名。
类型变量名
异常名
Python 中的异常均为类，因此其命名规范与类名一致。只不过你要在异常名的末尾加上 Error 后缀，尤其对于那些是错误的异常。
译注：Python 中的异常 (Exception) 通常指程序可以处理并使之恢复正常的那些“报错”；而错误 (Error) 通常指操作系统中的“报错”，程序本身对此无能为力，如 OSError, IOError。
全局变量名
（我们假设这里提到的全局变量仅用于单个模组内部。）全局变量的命名规范与函数相同。
对于某个模块，在通过 from Module import * 导入变量时，可以通过人为编写 __all__ 来规避将全局变量一同导入；也可以通过在全局变量名前面加上两个下划线来规避将其导入（这样的命名方法也暗示开发者只想让这些全局变量在本模块中使用）。
函数和一般变量名
函数的命名应该使用全小写字母，以下划线分割单词。（即蛇形命名法）
变量的命名与函数命名规范一致，如 some_random_variable。
至于小驼峰命名法，当且仅当前后文的代码已经使用小驼峰命名法时，为保证前后连贯一致才可使用。（如 threading.py 中的内容）
