本文档所提供的编码规范,适用于主要的Python发行版中组成标准库的Python代码。请参阅PEP关于Python的C实现的C编码风格指南的描述。
本文档和PEP257(文档字符串规范)改编自Guido的《Python Style Guide》一文,并从《Barry's style guide》添加了部分内容作为补充。
这篇风格指南随着时间的推移而逐渐演变,随着语言本身的变化,一些过去的约定已经过时,并确定了更多新的约定。
许多项目都有自己的编码风格指南。如果有任何冲突,优先使用该项目特定的指南。
愚蠢地坚持一致性是无知的妖怪
Guido的一个重要的见解是,代码阅读的次数比编写的次数多。这里提供的指南旨在提高代码的可读性,并使各种不同的Python代码一致。如PEP20所说,“可读性很重要”。
风格指南是关于一致性的。与本风格指南一致很重要。项目中的一致性更重要。一个模块或函数中的一致性最重要。
最重要的是:知道何时会不一致——有时风格指南就不适用了。怀疑时,作出你最佳的判断。看看其他的例子,并决定什么是最好的。不要犹豫,尽管发问!
特别地:不要只为遵从这个PEP而打破向后兼容性!
可以忽略部分风格指南的好理由,不要只为遵从这个PEP而打破向后兼容性!
忽视既定指南的一些其他的好理由:
- 当应用指南会降低代码的可读性,即使对于那些习惯遵照这个PEP来阅读代码的人来说。
- 与周围的代码保持一致也会破坏它(可能是历史原因)——虽然这也是收拾别人烂摊子的好机会(在真正的XP风格中)。
- 因为问题代码先于指南,又没有其它的修改理由。
- 代码需要兼容老版本,本风格指南不建议使用的Python特性。
代码布局
缩进
每级缩进用4个空格。
括号中使用垂直隐式缩进或使用悬挂缩进。当使用悬挂缩进时,应考虑以下内容:第一行上没有参数,后续行要有缩进。
·Yes:
# 与起始定界符对齐:
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)
No:
# 不使用垂直参数时,第一行不能有参数。
foo = long_function_name(var_one, var_two,
var_three, var_four)
# 参数的缩进与print()函数缩进相同。
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
对于连续的行而言,四个空格的规定不是必须的。
#悬挂缩进不一定是4个空格。
# Hanging indents *may* be indented to other than 4 spaces.
foo = long_function_name(
var_one, var_two,
var_three, var_four)
if 语句跨行时,两个字符关键字加上一个空格,再加上左括号构成了很好的缩进。后续行暂时没有规定,以下有三种格式,建议用三种:
# No extra indentation.没有额外的缩进
if (this_is_one_thing and
that_is_another_thing):
do_something()
# Add a comment, which will provide some distinction in editors.添加注释
# supporting syntax highlighting.
if (this_is_one_thing and
that_is_another_thing):
# Since both conditions are true, we can frobnicate.
do_something()
# Add some extra indentation on the conditional continuation line.
#额外添加缩进,推荐
if (this_is_one_thing
and that_is_another_thing):
do_something()
也请参阅下面的二进制操作符之前或之后是否要中断的讨论。
右边括号也可以另起一行。有两种格式,建议第2种。
# 右括号不回退,个人不推荐
my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)
# 右括号回退
my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)
空格或Tab?
-
空格是首选的缩进方法。
-
Tab仅仅在已经使用tab缩进的代码中为了保持一致性而使用。
-
Python 3中不允许混合使用Tab和空格缩进。
-
Python 2的包含空格与Tab和空格缩进的应该全部转为空格缩进。
Python2命令行解释器使用-t选项时有非法混合Tab和空格的情况会告警。当使用-tt警告提升为错误。强烈推荐这些选项!另外个人推荐pep8和autopep8模块。
最大行宽
限制所有行的最大行宽为79字符。
文本长块,比如文档字符串或注释,行长度应限制为72个字符。
多数工具默认的续行功能会破坏代码结构,使它更难理解,不推荐使用。但是超过80个字符加以提醒是必要的。一些工具可能根本不具备动态换行功能。
一些团队强烈希望更长的行宽。如果能达成一致,可以从从80提高到100个字符(最多99个字符)增加了标称线的长度,不过依旧建议文档字符串和注释保持在72的长度。
Python标准库比较保守,限制行宽79个字符(文档字符串/注释72)。
续行的首选方法是使用小括号、中括号和大括号反斜线仍可能在适当的时候。其次是反斜杠。比如with语句中:
with open('/path/to/some/file/you/want/to/read') as file_1, \
open('/path/to/some/file/being/written', 'w') as file_2:
file_2.write(file_1.read())
类似的还有assert。
应该在二进制操作符之前或之后续行吗?
几十年来,推荐的样式是在二进制运算符之后中断。但这可能会以两种方式损害可读性:操作员倾向于分散在屏幕上的不同列上,并且每个运算符从其操作数移动到上一行。在这里,眼睛必须做额外的工作,告诉哪些项目被添加,哪些被减去。
# No: operators sit far away from their operands.操作员坐在远离操作数的地方
income = (gross_wages +
taxable_interest +
(dividends - qualified_dividends) -
ira_deduction -
student_loan_interest)
为了解决这个可读性问题,数学家和他们的出版商遵循相反的惯例。Donald Knuth解释了他的计算机和排版系列中的传统规则:“虽然一个段落中的公式总是在二进制操作和关系之后断裂,但显示公式总是在二进制操作之前中断。”
遵循数学传统,通常会产生更多可读代码。
# Yes: easy to match operators with operands.易于与操作数匹配的运算符
income = (gross_wages
+ taxable_interest
+ (dividends - qualified_dividends)
- ira_deduction
- student_loan_interest)
在Python代码中,允许在二进制操作符之前或之后中断,只要约定在本地是一致的。对于新代码,Knuth的风格被提出。
空行
-
两行空行分割顶层函数和类的定义。
-
类的方法定义用单个空行分割。
-
额外的空行可以必要的时候用于分割不同的函数组,但是要尽量节约使用。
-
额外的空行可以必要的时候在函数中用于分割不同的逻辑块,但是要尽量节约使用。
-
Python接 contol-L作为空白符;许多工具视它为分页符,这些要因编辑器而异。
源文件编码
在核心Python发布的代码应该总是使用UTF-8(ASCII在Python 2)。
ASCII文件(Python 2)或UTF-8(Python 3)不应有编码声明。
标准库中非默认的编码应仅用于测试或当注释或文档字符串,比如包含非ASCII字符的作者姓名,尽量使用\x , \u , \U , or \N。
Python 3.0及以后版本,PEP 3131可供参考,部分内容如下:在Python标准库必须使用ASCII标识符,并尽量只使用英文字母。此外字符串和注释也必须用ASCII。唯一的例外是:(a)测试非ASCII的功能,和(b)作者的名字不是拉丁字母。
导入
-
导入在单独行
Yes: import os
import sys
No: import sys, os
这样说也可以
from subprocess import Popen, PIPE
-
导入始终在文件的顶部,在模块注释和文档字符串之后,在模块全局变量和常量之前。
导入顺序如下:标准库进口,相关的第三方库,本地库。各组的导入之间要有空行。
相关的all放在导入之后。
-
推荐绝对路径导入,因为它们通常更可读,而且往往是表现更好的(或至少提供更好的错误消息。
import mypkg.sibling from mypkg import sibling from mypkg.sibling import example
在绝对路径比较长的情况下,也可以使用相对路径:
from . import sibling
from .sibling import example
标准库代码应该避免复杂的包布局,并且总是使用绝对的导入。
在Python 3中不应该使用和删除隐式相对导入。
导入类的方法:
from myclass import MyClass
from foo.bar.yourclass import YourClass
如果和本地名字有冲突:
import myclass
import foo.bar.yourclass
禁止使用通配符导入。
通配符导入(from <module> import *)应该避免,因为它不清楚命名空间有哪些名称存,混淆读者和许多自动化的工具。唯一的例外是重新发布对外的API时可以考虑使用。
字符串引用
Python中单引号字符串和双引号字符串都是相同的。注意尽量避免在字符串中的反斜杠以提高可读性。
根据PEP 257, 三个引号都使用双引号。
表达式和语句中的空格
强制要求
括号里边避免空格
# 括号里边避免空格
# Yes
spam(ham[1], {eggs: 2})
# No
spam( ham[ 1 ], { eggs: 2 } )
在尾逗号和后面的括号之间。
Yes: foo = (0,)
No: bar = (0, )
逗号,冒号,分号之前避免空格
# 逗号,冒号,分号之前避免空格
# Yes
if x == 4: print x, y; x, y = y, x
# No
if x == 4 : print x , y ; x , y = y , x
索引操作中的冒号当作操作符处理前后要有同样的空格(一个空格或者没有空格,个人建议是没有。
Yes:
ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
ham[lower:upper], ham[lower:upper:], ham[lower::step]
ham[lower+offset : upper+offset]
ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
ham[lower + offset : upper + offset]
No:
ham[lower + offset:upper + offset]
ham[1: 9], ham[1 :9], ham[1:9 :3]
ham[lower : : upper]
ham[ : upper]
函数调用的左括号之前不能有空格
# Yes
spam(1)
dct['key'] = lst[index]
# No
spam (1)
dct ['key'] = lst [index]
赋值等操作符前后不能因为对齐而添加多个空格
# Yes
x = 1
y = 2
long_variable = 3
# No
x = 1
y = 2
long_variable = 3
其他建议