Python部落组织翻译，禁止转载
目录
缩进
制表符还是空格？
最大行长度
空行
源文件编码
导入
其他建议
评论块
内嵌评论
Doc弦乐
基本原理
简介简介
本文档中提供的编码规范适用于构成主要 Python 发行版中标准库的 Python 代码。请参阅 Python 的 C 实现的 C 编码风格指南的 PEP 描述 [1]。
本文档和 PEP257（文档字符串规范）改编自 Guido 的 《Python Style Guide》 文章，并补充了 Barry 的风格指南 [2]。
随着时间的推移，随着语言本身的变化，这种风格指南也在不断发展，使得过去的约定变得过时并确定新的约定。
许多项目都有自己的编码风格指南。如果存在任何冲突，则以项目特定指南为准。
令人讨厌的小人物的愚蠢一致性
Guido 的一个重要见解是，代码的读取次数多于编写次数。这里提供的指南旨在提高代码可读性并使各种不同的Python代码保持一致。正如 PEP20 所说，“易读性非常重要”。
风格指南注重一致性。与本风格指南保持一致非常重要。项目的一致性更为重要。模块或功能内的一致性是最重要的。
底线：知道何时要不一致——有时风格指南并不适用。如有疑问，请运用您的最佳判断。查看其他示例并决定什么是最好的。不要犹豫，快来询问吧！
特别：不要为了遵守此 PEP 而破坏向后兼容性！
忽略既定准则的其他一些充分理由：
1. 应用准则后，即使对于那些习惯于遵循本 PEP 阅读代码的人来说，准则也会降低代码的可读性。
2. 与周围的代码保持一致也会破坏它（可能是出于历史原因）——尽管这也是清理别人混乱的好机会（真正的 XP 风格）。
3。因为有问题的代码先于指南，所以没有其他原因需要修改。
4。该代码需要与旧版本兼容。本风格指南不建议使用 Python 功能。
代码布局
缩进
每级缩进使用 4 个空格。
连续行应与折叠元素对齐，可以垂直使用 Python 的括号内、方括号内、花括号内的隐式行连接，或使用悬挂缩进 [5]。使用悬挂压痕时应注意以下几点；
第一行没有参数，并使用更多缩进来与后续行区分开。
好风格：
不良风格：
对于连续行，4 空格规则是可选的。
可选：
当if语句条件块足够长时，需要写多行。值得注意的是，两个字符的关键字（例如 if）加上一个空格和一个左括号会为多行条件的后续行创建 4。用于缩进的空格。这可能会与 if 中嵌入的缩进语句产生视觉冲突，这些语句自然缩进 4 个空格。本 PEP 没有阐明如何进一步区分 (if) 条件行和 if 语句中的嵌入行。在这种情况下，可接受的选项包括但不限于：
多行结构中的右大括号/方括号/圆括号是最后一行的第一个非空白字符，例如：
或最后一行的第一个字符，如：
制表符还是空格？
空格是首选的缩进方法。
制表符仅用于与使用制表符缩进的代码保持一致。
Python3 不允许混合制表符和空格进行缩进。混合使用制表符和空格进行缩进的
Python 2 代码将转换为仅使用空格。
调用Python2命令行解释器时使用-t选项来警告代码中制表符和空格的非法混合。使用 -tt 选项时，警告将变成错误。强烈推荐这些选项！
最大线路长度
将所有行限制为最多 79 个字符。
下垂的长块结构仅限于较少的文本（文档字符串或注释），并且行长度应限制为 72 个字符。
限制编辑器窗口宽度可以并排打开多个文件，并且使用代码审查工具显示相邻列的两个版本效果很好。
大多数工具的默认折叠会破坏代码的视觉结构，使其更难以理解。编辑器中的窗口宽度设置为 80 个字符。甚至该工具也会在最后一列中标记字形。某些基于网络的工具可能不提供动态自动换行。
一些团队强烈喜欢更长的线路长度。对于完全或主要由一个团队维护的代码，可以就此问题达成一致，并且行长度从 80 个字符名义增加到 100 个字符（有效地将最大长度增加到 99 个字符）也是可以接受的，前提是注释和文档字符串仍然存在72 个字符。
Python 标准库采取保守方法，要求行限制为 79 个字符（文档字符串/注释为 72 个字符）。
折叠长行的首选方法是在括号、方括号和大括号内使用 Python 隐式换行符。通过在表达式两边使用括号，可以将长行分成多行。连续行最好使用反斜杠。
反斜杠有时仍然是合适的。例如，长多行with语句不能使用隐式续行，但可以使用反斜杠：
（有关 With 语句的多行缩进的进一步思考，请参阅前面对多行 if 语句的讨论。）
另一个这样的例子是assert语句。
确保连续行正确缩进。
换行符应该在二元运算符之前还是之后？
在过去的二十年里，我们建议将它放在二元运算符之后。但这种方法在两个方面损害了可读性：多个二元运算符不在屏幕上的一列中，如果您想知道对操作的对象做了什么，则需要向上一行。这导致您的眼睛必须上下移动很多次才能弄清楚哪个数字正在被添加，哪个数字正在被减去：
为了解决可读性问题，数学家和打印机经常在二进制运算符之前换行。 Donald Knuth 在他的 《计算机与排版》 系列文章中解释了这一传统规则：“虽然段落中编写的公式通常在二元运算符之后换行，但单独呈现的公式通常在二元运算符之前。换行。”
按照数学传统，如果我们这样写代码会更具可读性：
空行
顶层函数的定义和类之间有两个空行。
类内部的函数定义之间有一个空行。
额外的空行用于（谨慎地）分隔相关的功能组。不要在相关行之间使用空行（例如：一组虚拟实现）。
谨慎使用空行来表示函数内的逻辑部分。
Python 接受 control-L（即 ^L）换页符作为空白字符；许多工具将这些字符视为分页符，因此您可以使用它们来分页到文件的相关部分。请注意，某些编辑器和基于 Web 的代码查看器可能无法将 control-L 识别为页面更改，并会显示不同的字形。
源文件编码
核心 Python 发行版中的代码应始终使用 UTF-8（或 Python 2 中的 ASCII）。
使用 ASCII (Python 2) 或 UTF-8 (Python 3) 的文件不应具有编码声明。
在标准库中，非默认编码仅用于测试目的，或者注释或文档字符串需要提及包含非 ASCII 字符的作者姓名；否则，使用 \x、\u、\U 或 \N 字符 在字符串中包含非 ASCII 数据的第一种方法。
Python 3.0 及更高版本，为标准库指定了以下策略（请参阅 PEP 3131）：Python 标准库中的所有标识符必须使用 ASCII 标识符，在可行的情况下使用英文单词（在许多情况下，使用非英语缩写和技术术语）。此外，字符串和注释必须采用 ASCII 格式。唯一的例外是 (a) 测试非 ASCII 功能和 (b) 测试作者姓名。姓名不是基于拉丁字母的作者必须提供其姓名的拉丁字母音译。
开源项目是全球性的，鼓励统一的策略。
导入
导入通常在单行上，例如：
良好的风格：
不良风格：
这个也可以：
导入通常位于文件顶部、模块注释和字符串文档之后、模块全局变量和常量之前。
导入应按以下顺序分组：
1。标准库导入
2。相关第三方进口
3.特定本地应用程序/库导入
在每个导入组之间放置一个空行。
导入后放置任何相关的 __all__ 规格。
建议使用绝对导入，因为如果导入系统配置不正确（例如，当包中的目录以 sys.path 结尾时），它们更具可读性并且性能更好（至少给出更好的错误消息）：
如果这种写法导致本地名称冲突，那么这样写：
并使用“myclass.MyClass”和“foo.bar.yourclass.YourClass”来访问。
避免使用通配符导入（from <模块名> import *），因为它们会使命名空间中出现哪些名称变得不清楚，这会让读者和许多自动化工具感到困惑。通配符导入的一个合理用例是将内部接口重新分发为公共 API 的一部分（例如，覆盖从可选加速器模块定义的接口的纯 Python 实现，并且哪些定义将被提前重写不知道） ）。
以这种方式重命名，以下有关公共和内部接口的准则仍然适用。
模块级别的内置属性
模块级内置属性（名称前后带有双下划线），例如 __all__、__author__、__version__，应放置在模块的文档字符串之后和任何导入语句之前，除了从 __future__ 导入之外。 Python 强制 from __future__ 导入必须出现在任何代码之前，并且只能出现在模块级文档字符串之后。
字符串引号
在Python中，单引号字符串和双引号字符串是相同的。本 PEP 不建议这样做。建议选择一条规则并遵守它。当字符串包含单引号或双引号字符时，请使用其他类型的字符串引用以避免字符串中出现反斜杠。这提高了可读性。
三引号字符串，与 PEP 257 文档字符串规范一致，始终使用双引号字符。
表达式和语句中的空格
难以忍受
在以下情况下避免使用额外的空格：
位于圆括号、方括号或大括号之后。
紧邻逗号、分号或冒号之前：
在切片中，冒号的作用类似于二元运算符，冒号两侧的空格数量相同（将其视为优先级最低的运算符）。在扩展切片中，两个冒号必须具有相同数量的空格。例外：当省略切片参数时，空格也被省略。
紧邻左括号之前，函数调用的参数列表的开头：
紧邻索引或切片开头的左括号之前：
多个空格可与另一赋值（或其他）运算符对齐。
其他建议
始终避免尾随空格。因为它们通常是不可见的，所以可能会导致混乱：如果 \ 后面跟有空格，则它不是有效的行继续字符。许多编辑器不保存尾随空格，CPython 项目还设置预提交检查以拒绝尾随空格的存在。
始终在这些二元运算符的两侧放置一个空格：赋值 (=
），增强分配（+=，-=
等），比较（==，< ， >，！=，<>，<= ， >=，在，不是
in、is、is not）、布尔值（与、或、非）。
如果使用不同优先级的运算符，请在优先级较低的运算符周围添加空格。请勿使用多个空格。二元运算符两侧的空格数必须相同。
当 = 符号用于指示关键字参数或默认参数值时，请勿在 = 符号两边使用空格。
带注释的函数使用正常的冒号规则，并在 -> 的两侧添加一个空格：
如果参数同时有注释和默认值，则在等号两边加一个空格（只有当同时有注释和默认值时才添加此空格）。
不鼓励使用复合语句（同一行上的多个语句）。
何时使用尾随逗号？
尾随逗号通常是可选的，但在某些强制性场景中除外，例如当元组只有一个元素时需要尾随逗号。为了让代码更清晰，当元组只有一个元素时一定要用括号括起来（没有语法要求）：
如果您在不需要尾随逗号时使用版本控制系统，这会很有用。当列表元素、参数和导入项将来可能会继续增加时，保留尾随逗号是一个不错的选择。通常的用法是（例如列表）每个元素都在自己的行上，末尾带有逗号，并且在最后一个元素之后的下一行写入结束标记。如果您的数据结构写在同一行，则无需保留尾随逗号。
笔记
与代码相矛盾的注释比没有注释更糟糕。当代码修改时，一定要先更新注释！
评论应该是完整的句子。如果注释是短语或句子，则其第一个单词的第一个字母应大写，除非它是以小写字母开头的标识符（不更改标识符！）。
如果评论很短，则无需在末尾添加句号。注释块通常由一个或多个由完整句子组成的段落组成，每个句子应以句点结尾。
在句末句号后使用两个空格。
撰写英文注释时，请遵循断词和空格。
非英语 Python 程序员：请用英语撰写注释，除非您 120% 确定查看您代码的每个人都与您使用相同的语言。
非英语 Python 程序员：请用英语写下您的注释，除非您 120% 确定代码不会被不懂您语言的人阅读。
评论区
注释块通常适用于紧随其后的部分（或全部）代码，并且这些代码应使用相同级别的缩进。注释块的每一行都以 # 和空格开头（除非注释中的文本是缩进的）。
注释块中的段落由仅包含 # 的行分隔。
内嵌评论
谨慎使用内联注释。
行内注释是注释和代码在同一行，与代码至少用两个空格分隔。它以 # 和一个空格开头。
如果内嵌注释指出了显而易见的事情，那么它是不必要的。不要这样做：
但有时，这很有用：
文档字符串
书面文档字符串（即“代码”）约定在 PEP 257 中永垂不朽。
为所有公共模块、函数、类和方法编写文档字符串。没有必要为非公共方法编写文档字符串，但您应该编写注释来描述该方法的用途。这些注释应该写在 def 行之后。
PEP 257 描述了良好的文档字符串约定。最重要的是，多行文档字符串以行“””结尾，例如：
对于只有一行的文档字符串，“””位于同一行。
命名约定
Python 库的命名约定有点混乱，所以我们不会让它们完全一致 - 然而，这是当前推荐的命名标准。新的模块和包（包括第三方框架）应根据这些标准编写，但对于风格不同的现有库，首选内部一致性。
基本原理
用户可见的 API 公共部分的名称应遵循反映用法而不是实现的约定。
说明：命名风格
有许多不同的命名风格。它有助于识别所使用的命名风格，而与他们的角色无关。
以下命名方式是最常见的：
b（单个小写字母）
B（单个大写字母）
小写字符串
带下划线的小写字符串
大写字符串
带下划线的大写字符串
第一个字母大写的字符串（或 CapWords，或驼峰式大小写 - 如此命名是因为字母看起来不均匀 [3]）。有时也称为 StudlyCaps。
注意：在 CapWords 中使用缩写时，请将所有缩写字母大写。因此 HTTPServerError 比 HttpServerError 更好。
混合大小写的字符串（与大写字符串不同，它以小写字母开头）
带下划线的大写字符串（恶心！）
还有一种风格使用简短的唯一前缀将相关名称组织在一起。这在 Python 中很少使用，但为了文档的完整性而提及。例如，os.stat()函数返回一个元组，其元素名称通常类似于st_mode、st_size、st_mtime等（这样做是为了强调与POSIX系统调用结构的一致性，这有助于程序员熟悉这些结构）。
X11库的所有公共函数都以X开头。在Python中，这种风格通常被认为是不必要的，因为属性名称和函数名称以对象名称为前缀，函数名称以模块名称为前缀。
此外，还可以识别以下特殊形式（前导或尾随下划线）（并且通常可以与任何约定组合）：
单前导下划线：弱“内部使用”标志。例如， from M import * 不会导入以下划线开头的对象。
单尾下划线：按惯例使用以避免与 Python 关键字冲突，例如
Tkinter.Toplevel(master, class_='ClassName')
双前导下划线：命名类属性时，名称会在调用时进行调整（在类 FooBar 中，__boo 变为 _FooBar__boo；见下文）。
前导和尾随双下划线：存在于用户控制的命名空间中的“神奇”对象或属性。
例如：__init__、__import__ 或 __file__。不要创建这样的名称；仅按照文档中的说明使用它们。
规则：命名约定
要避免的名字
请勿使用字符“l”（小写字母 el）、“O”（大写字母 oh）或“I”（大写字母 eye）作为单字符变量名称。
在某些字体中，这些字符与数字 1 和 0 无法区分。当您想使用“l”时，请使用“L”代替。
包名称和模块名称
模块名称应简短，所有字母均为小写。您可以在模块名称中使用下划线以提高可读性。 Python 包名称也应该简短，所有字母均为小写，不鼓励使用下划线。
当用 C 或 C++ 编写的扩展模块附带 Python 模块以提供更高级别（例如，更面向对象）的接口时，C/C++ 模块名称具有前导下划线（例如，_socket）。
班级名称
类名通常采用字符串首字母大写的规则。
函数的命名规则主要用于可调用函数。
接口录制且主要用于调用时，使用函数的命名规则，而不是类名的命名规则。
请注意，内置名称有一条单独的规则：大多数内置名称是一个单词（或两个单词在一起），并且大写字符串的规则仅适用于异常名称和内置常量。
输入变量名称
类型变量名称首字母大写且尽可能短，如：T、AnyStr、Num。对于协变量和具有协变行为的变量，建议添加后缀 __co 或 __contra。
异常名称
因为异常应该是类，所以类的命名规则也适用于此。但是，异常名称（如果异常确实是错误）应具有后缀“Error”。
全局变量名
（希望这些变量在模块内使用。）这些规则与函数的规则相同。
设计为通过 from M import * 使用的模块应该使用 __all__ 机制来防止导出全局变量，或者使用在全局变量前加下划线的旧规则（也许你想表明这些全局变量是“非公共的”） “模块”）。
功能名称
函数名称应使用小写字母，必要时用下划线分隔单词以提高可读性。
混合大小写仅在这种风格已经占主导地位的上下文中使用（例如 www.sychzs.cn），以保持向后兼容性。
函数和方法参数
使用self作为实例化方法的第一个参数。
使用cls作为类方法的第一个参数。
如果函数的参数名称与保留关键字冲突，最好在参数名称后面添加下划线，而不是使用缩写或拼写错误。
所以class_比classs好。 （也许最好使用同义词来避免。）。
方法名称和实例变量
使用函数命名规则：小写字母，必要时用下划线分隔单词以提高可读性。
仅对非公共方法和实例变量使用前导下划线。
为了避免与子类发生命名冲突，请使用两个前导下划线来调用 Python 的名称修饰规则。
Python 将这些名称与类名称相适应：如果类 Foo 有一个名为 __a 的属性，则无法通过 Foo.__a 访问它。 （可以通过调用 Foo._Foo__a 来访问。） 通过
通常，两个前导下划线仅用于避免与子类属性名称冲突。
注意：关于 __names 的使用存在一些争论（见下文）。
恒定
常量通常在模块级别定义，并且全部采用大写字母，单词之间用下划线分隔。例如 MAX_OVERFLOW 和 TOTAL。
传承设计
确定类的方法和实例变量（统称为“属性”）是否是公共的。如有疑问，请选择私人；稍后将其公开比将公共财产改为私有财产更容易。
公共属性是您希望与您的类无关的客户端使用的属性，这符合您避免向后不兼容更改的承诺。非公共属性是指那些不打算被第三方使用的属性；您无法保证非公共属性不会被更改甚至删除。
非公开属性是指不打算供第三方使用的属性，您不能保证非公开属性不会被更改甚至删除。
这里没有使用术语“私有”，因为Python中没有真正的私有属性（没有通常不必要的工作）。
另一类属性是“API 子集”的一部分（在其他语言中通常称为“受保护”）。有些类被设计为基类，可以扩展或修改类行为的某些方面。设计这样的类时，请小心明确哪些属性是公共的，哪些是 API 子类的一部分，哪些实际上只在基类中使用。
先不说这些，这里有一份 Python 功能指南：
公共属性没有前导下划线。
如果公共属性名称与保留关键字冲突，请在属性名称后面添加下划线。这比缩写或拼写错误更好。 （然而，尽管有这样的规定，“cls”是任何类变量或参数的首选拼写，尤其是类方法的第一个参数）
注 1：请参阅上面有关类方法参数名称的建议。
对于简单的公共数据属性，最好只公开属性名称，而不需要复杂的访问器/修改器方法。请记住，Python 为未来的增强提供了一条简单的途径，您应该找到需要添加功能行为的简单数据属性。在这种情况下，使用属性来隐藏简单数据属性访问语法背后的功能。
注 1：该功能仅适用于新样式类。
但要尽量保持功能行为没有副作用，尽管像缓存这样的副作用通常是好的。
注意 3：避免将属性用于计算开销较大的操作。属性注释使调用者相信访问（相对）便宜。
如果您确定您的类将被子类化并且具有您不希望子类使用的属性，请考虑使用两个前导下划线命名它们，并且不使用尾随下划线。这将调用Python的名称修饰算法，类名将被修饰为属性名称。当子类无意中包含相同的属性名称时，这有助于避免属性名称冲突。
注1：注意适配名称仅用于简单的类名，如果子类使用相同的类名和属性名，仍然会出现名称冲突。 ？然而，名称修饰算法有很好的文档记录，并且很容易手动实现。
注3：并不是每个人都喜欢名字改编。尝试平衡避免意外名称冲突与高级呼叫者的可能性。
公共和内部接口
任何向后兼容性保证仅适用于公共接口。因此，用户能够清楚地区分公共接口和内部接口非常重要。
记录的接口被视为公共接口，除非文档明确声明它们是临时或内部接口，不受通常的向后兼容性保证。所有未记录的接口都应假定为内部接口。
为了更好地支持自省，模块应该使用 __all__ 属性来显式声明其公共 API 的名称。 __all__ 设置为空列表，表示该模块没有公共 API。
即使正确设置了 __all__，内部接口（包、模块、类、函数、属性或其他名称）仍应以下划线为前缀。
如果接口包含任何被视为内部的命名空间（包、模块或类），则该接口被视为内部的。
导入名称被视为实现细节。其他模块不得依赖于对此导入名称的间接访问，除非它们是显式记录的包含模块 API 的一部分，例如 os.path 或公开子模块功能的包的 __init__ 模块。
编程建议
代码的编写方式不应影响其他 Python 实现方式（PyPy、Jython、IronPython、Cython、Psyco 等）。
例如，不要依赖CPython的高效语句形式进行字符串连接
+= b 或 a = a +
b.即使在 CPython 中，这种优化也很脆弱（它只适用于某些类型），并且在不使用引用计数的实现中完全不存在。在库的性能敏感部分，应使用 ''.join() 形式。这将确保不同实现之间的连接在线性时间内发生。
要与单个值（例如 None）进行比较，请使用 is 或 is not。不要使用等号运算符。
同样，如果您的真正意思是“if x is not None”，请注意不要写“if x”。例如，测试默认为 None 的变量或参数是否设置为其他值时。该其他值的类型在布尔上下文（例如容器）中可能为 false。
使用 is not 运算符代替 not...is。虽然这两个表达式做同样的事情，但前者更具可读性和优越性。
在实现具有丰富比较的排序操作时，最好实现所有六个运算符（__eq__、__ne__、__lt__、__le__、__gt__、__ge__），而不是依赖其他代码只执行一项特定比较。
为了减少所涉及的工作量， www.sychzs.cn_ordering() 装饰器提供了一个工具来生成缺失的比较函数。
PEP
207 表明Python 假定自反规则。因此，编译器可以交换 y > x 和 x < y，y >= x 和 x <=
y，您还可以交换参数 x == y 和 x != y。 sort() 和 min() 操作保证使用 < 操作符并且max()功能使用>
操作员。无论如何，最好实现所有六个操作，这样在其他上下文中就不会造成混乱。
使用 def 语句而不是赋值语句将 lambda 表达式绑定到标识符。
从 Exception 而不是 BaseException 派生异常。从 BaseException 直接继承保留了几乎总是错误捕获的异常。
设计异常层次结构基于区别，代码可能需要捕获异常而不是引发异常的位置。旨在以编程方式回答“出了什么问题？”的问题。而不是仅仅说“发生了问题”（有关本课程学习内置异常层次结构的示例，请参阅 PEP 3151）
类的命名规则适用于此，但当异常确实是错误时，需要在异常类名中添加“Error”后缀。非错误异常用于非本地流量控制或其他形式的信令，不需要特殊后缀。
适当使用异常链。在Python 3中，“raise X from Y”用于指示显式替换，而不会丢失最初跟踪的信息。
有意替换内部异常时（Python
2 使用“raise X”，Python 3.3+ 使用“raise X from
”
None”），确保相关细节转移到新的异常中（例如在将 KeyError 转换为 AttributeError 时保留属性名称，或者将原始异常的文本嵌入到新的异常消息中）。
Python 3 中发生异常时，使用 raise ValueError('message') 替换旧形式 raise ValueError,'message'。
后一种形式是非法的 Python 3 语法。
当前使用的形式意味着当异常的参数很长或包含格式字符时，由于括号的缘故，不需要使用续行符。
捕获异常时，只要有可能，请提及特定的异常，而不是使用空的 except: 子句。
例如，使用：
异常：（空异常相当于 except BaseException:）
一个好的经验法则是将空“except”子句的使用限制为两种情况：
1。异常处理程序是否将打印或记录跟踪；至少用户会意识到发生了错误。
2.如果代码需要做一些清理工作，但是然后让异常用raise抛出。最好使用 try...finally 来处理这种情况。
当使用名称绑定捕获异常时，首选 Python 2.6 中添加的显式名称绑定语法。
这是 Python 3 中唯一支持的语法，避免了与旧的基于逗号的语法相关的歧义问题。
捕获操作系统异常时，更喜欢Python 3.3中引入的清晰的异常层次结构，并通过errno值进行内省。
此外，与所有 try/ except 子句一样，将 try 子句限制为所需的绝对最小代码量。这可以避免掩盖错误。
当资源是本地特定代码段时，使用with语句可以保证使用后快速可靠地清理掉。您还可以使用 try/finally 语句。
每当您执行除获取或释放资源之外的某些操作时，您应该通过单独的函数或方法调用上下文管理器。例如：
后一个示例除了在事务结束后关闭连接之外，没有提供有关 __enter__ 和 __exit__ 方法执行哪些操作的信息。在这种情况下，清晰度很重要。
返回语句保持一致。函数中的所有 return 语句都有返回值，或者没有返回值。如果任何 return 语句有返回值，则任何没有返回值的 return 语句都应显式声明 return None，并且显式 return 语句应放在函数末尾（如果可能）。
使用字符串方法而不是字符串模块。
字符串方法总是更快，并且使用与 unicode 字符串相同的 API。如果必须向后兼容Python 2.0之前的版本，请忽略这个原则。
使用“.startswith()”和“.endswith()”代替字符串切片来检查前缀和后缀。
startswith()和endswith()更加清晰，降低错误率。例如：
对象类型的比较使用 isinstance() 而不是直接比较类型。
检查对象是否为字符串时，请记住它也可能是 unicode 字符串！在Python 2中，str和unicode有一个共同的基类basestring，所以你可以这样做：
注意，在Python3中，unicode和basestring不再存在（只有str），字节对象不再是字符串（而是整数序列）
对于序列（字符串、列表、元组），使用 The事实上，空序列是错误的。
不要编写依赖于尾随空格的字符串。这些尾随空格在视觉上无法区分，一些编辑器（或者最近的www.sychzs.cn）会将它们删除。
不要使用==来比较布尔值与True或False。
Python 标准库不使用函数注释，因为这会导致过早地承诺特定的注释样式。相反，评论留给用户来发现和尝试有用的评论样式。
建议第三方实验注释使用相关修饰符来指示解释器应如何解释注释以对注释进行实验。
早期核心开发人员尝试使用显示不一致的临时注释样式的函数注释。例如：
[str] 是不明确的，无论它表示字符串列表还是可以是 str 或 None 的值。
当值是 bytes 或 str 时，使用符号 open(file:(str,bytes))，而不是包含 str 后跟 bytes 值的元组。
seek(whence:int) 注释表现出额外和内部规范的混合：int 限制性太大（任何带有 __index__ 的内容都将被允许），并且限制性不够（只有值 0、1、且允许 2）。同样， write(b:bytes) 注释的限制性太大（任何支持缓冲协议的内容都将被允许）。
一些注释例如 read1(n:int=None) 是矛盾的，因为 None 不是 int 值。一些注释（例如 assource_path(self,fullname:str) -> object）的返回类型令人困惑。
除了以上的，注解在具体类型和抽象类型的使用上是不一致的：int与Integral相对，set/frozenset与MutableSet/Set相对。
抽象基类的一些注解是不正确的规范。例如，set-to-set操作需要Other是另一个Set的实例而不是一个Iterable。
另一个问题是注解成为规范的一部分，但它没有被测试。
在大多数情况下，文档字符串已经包含了类型规范，并且比函数注解更清晰。在其余的情况下，一旦注解被移除文档字符串将改进。
所见到的函数注解太特别而且与一个自动类型检查或参数验证的连贯系统不一致。在代码中留下这些注解将使它以后更难做出改变以便自动化工具支持。
脚注
[5]悬挂缩进是段落中除第一行之外其它所有行都缩进的格式。在Python中，这个术语用来描述左括号括起来的语句，这行的最后非空白的字符，随后行缩进，直到右括号。
参考
[1]PEP 7，van Rossum写的C编码风格指南
[2]Barry的GNU Mailman风格指南
http://www.sychzs.cn/software/STYLEGUIDE.txt
[3]http://www.sychzs.cn/wiki/CamelCase
[4]PEP 8现代化，2013年7月http://www.sychzs.cn/issue18472
版权
这个文档已经放置在公共领域。
来源：https://www.sychzs.cn/peps/file/tip/pep-0008.txt
英文原文: https://www.sychzs.cn/dev/peps/pep-0008/
译者: wangyc
-->
