代码风格指南、代码之禅

更新: 2025/2/24 字数: 0 字时长: 0 分钟

到这里我们已经学习完了所有的 Python 语言基础，尽管我们可以在保证语法没有问题的前提下随意书写 Python 代码，但是在实际开发中，采用一致的风格书写出可读性强的代码是每个专业的程序员应该做到的事情，也是每个公司的编程规范中会提出的要求，这些在多人协作开发一个项目（团队开发）的时候显得尤为重要。

代码风格指南

Python 增强提案（英文 Python Enhancement Proposal，缩写 PEP）是一个由 Python 社区的核心开发者和用户发起和讨论的用来改进 Python 语言或其标准库的提议。每个 PEP 都是一份指导 Python 往更好的方向发展的技术文档，其中的第 8 号增强提案（PEP 8）是针对 Python 语言编订的代码风格指南，我们可以从 Python 官方网站的 PEP 8链接中找到该文档，下面对该文档关键部分做一个简单的总结。

导包规则

PEP 8 对于导包的风格有着明确且严格的限制，具体归纳为如下三点：

import 语句总是放在文件开头的地方。
引入具体方法比引入整个模块更好，例如 from math import sqrt 就比 import math 更好。
如果有多个 import 语句，应该将其分为三部分，每个部分内部应该按照模块名称的字母表顺序来排列。这三个从上到下分别是：
- 最先引入 Python 标准库，且按字母表的顺序导入（re、time...）。
- 然后引入第三方库（requests、scrapy...）。
- 最后引入自定义模块（my_module）。

建议

在 PyCharm 中使用 Ctrl + Alt + O 快捷键，可以快速规整导包的语句的排布。

标识符命名

PEP 8 倡导用不同的命名风格来命名 Python 中不同的标识符，以便在阅读代码时能够通过标识符的名称来确定该标识符在 Python 中扮演了怎样的角色。

变量、函数和属性应该使用小写字母来拼写，如果有多个单词就使用下划线进行连接。
类中受保护的实例属性，应该以一个下划线开头。
类中私有的实例属性，应该以两个下划线开头。
类和异常的命名，应该每个单词首字母大写。
模块级别的常量，应该采用全大写字母，如果有多个单词就用下划线进行连接。
类的实例方法，应该把第一个参数命名为 self 以表示对象自身。
类的类方法，应该把第一个参数命名为 cls 以表示该类自身。

提醒

在标识符命名这点上，Python 自己的内置模块以及某些第三方模块都做得并不是很好。

缩进|空格|空行

PEP 8 中也规范了缩进、空格、空行的使用，具体如下：

缩进就是代码开头的位置与行开头位置之间的空格，Python 通过缩进来表示代码的层级关系，因此同一级的代码，必须写在同一个缩进下面。
每行的字符数不要超过 79 个字符，如果表达式太长而占据了多行，除了首行之外的其余各行都应该在正常的缩进宽度上再加上 4 个空格。
如果在不该有空格的位置出现了多余的空格或者在需要缩进的时候没有缩进，程序都会报 IndentationError 缩进异常。
函数和类的定义，前后要用两个空行进行分隔。在同一个类中，各个方法之间用一个空行进行分隔。

多行显示

PEP 8 中也提示了一条语句在多行显示或者多条语句写在一行的语法，具体如下：

一条语句在多行显示，在需要换行的地方加反斜杠（\），然后再换行。

python

print('ccc\
       ccc\
       ccc')

字典、列表、集合和元组等容器类型数据的字面量，在多行显示的时候可以直接换行。

python

print(1, 2, 3, 
      4, 5, 6,
      7, 8, 9,)

一条语句结束可以不写分号 ; 但是如果一行中要写多条语句，那么每条语句之间必须使用分号隔开。

python

print('aaa'); print('bbbb')

表达式

PEP 8 中也包含了关于表达式写法的建议，具体三点如下：

采用内联形式的否定词，而不要把否定词放在整个表达式的前面。例如 if a is not b 就比 if not a is b 更容易让人理解。
不要用检查长度的方式来判断字符串、列表等是否为 None 或者没有元素，应该用 if not x 这样的写法来检查它。
就算 if 分支、for 循环、except 异常捕获等中只有一行代码，也不要将代码和 if、for、except 等写在一起，分开写才会让代码更清晰。

代码之禅

在本章节的最后，我们用一段话来阐述 Python 这门编程语言的核心思想，这段话也被称之为代码之禅（执行 import this 查看），可以概括为如下一段话：

Beautiful is better than ugly. （优美比丑陋好）
Explicit is better than implicit.（清晰比晦涩好）
Simple is better than complex.（简单比复杂好）
Complex is better than complicated.（复杂比错综复杂好）
Flat is better than nested.（扁平比嵌套好）
Sparse is better than dense.（稀疏比密集好）
Readability counts.（可读性很重要）
Special cases aren't special enough to break the rules.（特殊情况也不应该违反这些规则）
Although practicality beats purity.（但现实往往并不那么完美）
Errors should never pass silently.（异常不应该被静默处理）
Unless explicitly silenced.（除非你希望如此）
In the face of ambiguity, refuse the temptation to guess.（遇到模棱两可的地方，不要胡乱猜测）
There should be one-- and preferably only one --obvious way to do it.（肯定有一种通常也是唯一一种最佳的解决方案）
Although that way may not be obvious at first unless you're Dutch.（虽然这种方案并不是显而易见的，因为你不是那个荷兰人【这里指的是 Python 之父 Guido】）
Now is better than never.（现在开始做比不做好）
Although never is often better than right now.（不做比盲目去做好【极限编程中的 YAGNI 原则】）
If the implementation is hard to explain, it's a bad idea.（如果一个实现方案难于理解，它就不是一个好的方案）
If the implementation is easy to explain, it may be a good idea.（如果一个实现方案易于理解，它很有可能是一个好的方案）
Namespaces are one honking great idea -- let's do more of those!（命名空间非常有用，我们应当多加利用）

代码风格指南、代码之禅 ​