PEP

8

Title

Style Guide for Python Code

Version

c451868df657

Last-Modified

2016-06-08 10:43:53 -0400 (Wed, 08 Jun 2016)

Author

Guido van Rossum <guido at python.org>, Barry Warsaw

<barry at python.org>, Nick Coghlan <ncoghlan at gmail.co m>

Status

Active

Type

Process

Content-Type:

text/x-rst

Created

05-Jul-2001

Post-History

05-Jul-2001, 01-Aug-2013

Introduction 介绍

本文提供的Python代码编码规范基于Python主要发行版本的标准库。Python的C语言实现的C代码规范请查看相应的PEP指南[1]。

这篇文档以及PEP 257（文档字符串的规范）改编自Guido原始的《Python Style Guide》一文，同时添加了一些来自Barry的风格指南[2]。这篇规范指南随着时间的推移而逐渐演变，随着语言本身的变化，过去的约定也被淘汰了。

许多项目有自己的编码规范，在出现规范冲突时，项目自身的规范优先。

A Foolish Consistency is the Hobgoblin of Little Minds 尽信书,则不如无书

Guido的一条重要的见解是代码阅读比写更加频繁。这里提供的指导原则主要用于提升代码的可读性，使得在大量的Python代码中保持一致。就像PEP 20提到的，“Readability counts”。

这是一份关于一致性的风格指南。这份风格指南的风格一致性是非常重要的。更重要的是项目的风格一致性。在一个模块或函数的风格一致性是最重要的。

然而，应该知道什么时候应该不一致，有时候编码规范的建议并不适用。当存在模棱两可的情况时，使用自己的判断。看看其他的示例再决定哪一种是最好的，不要羞于发问。

特别是不要为了遵守PEP约定而破坏兼容性！ 几个很好的理由去忽略特定的规则：

1. 当遵循这份指南之后代码的可读性变差，甚至是遵循PEP规范的人也觉得可读性差。

2. 与周围的代码保持一致（也可能出于历史原因），尽管这也是清理他人混乱（真正的Xtreme Programming风格）的一个机会。

3. 有问题的代码出现在发现编码规范之前，而且也没有充足的理由去修改他们。

4. 当代码需要兼容不支持编码规范建议的老版本Python。

Code lay-out 代码布局Indentation 缩进

每一级缩进使用4个空格。

续行应该与其包裹元素对齐，要么使用圆括号、方括号和花括号内的隐式行连接来垂直对齐，要么使用挂行缩进对齐[7]。当使用挂行缩进时，

# 与左括号对齐

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)