Python代码的良好习惯

Posted 2022-03-07 林炜玮_51CTO

​可读性才重要（Readability counts），我认同提高代码规范意识是学编程的第一课，不以规矩，不能成方圆​

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 arent 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 youre Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, its a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- lets do more of those!

优美胜于丑陋（Python 以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测
而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）

简介

PEP:	8
Title:	Style Guide for Python Code
Author:	Guido van Rossum , Barry Warsaw , Nick Coghlan
Translation:	鱼C工作室
Status:	Active
Type:	Process
Created:	05-Jul-2001
Post-History:	05-Jul-2001, 01-Aug-2013

​如果遇到以下情况，则可以忽略这份风格指南：​

• 当采用风格指南时会让代码更难读，甚至对于习惯阅读遵循这篇 PEP 的代码的人来说也是如此
• 需要和周围的代码保持一致性，但这些代码违反了指南中的风格（可是时历史原因造成的）——尽管这可能也是一个收拾别人烂摊子的机会（进入真正的极限编程状态）
• 若是有问题的某段代码早于引入指南的时间，那么没有必要去修改这段代码
• 代码需要和更旧版本的 Python 保持兼容，而旧版本的 Python 不支持风格指南所推荐的特性

​代码布局​

​缩进​

​每个缩进级别采用 4 个空格。连续行所包装的元素应该要么采用 Python 隐式排列，即垂直对齐于圆括号、方括号和花括号或者采用悬挂缩进，采用悬挂缩进时需考虑：第一行不应该包括参数，并且在续行中需要再缩进一级以便清楚表示​

提倡：
# 同开始分界符(左括号)对齐
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)

二元运算符

# 正确的例子：更容易匹配运算符与操作数
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

空行

使用 2 个空行来分隔最外层的函数（function）和类（class）定义。
使用 1 个空行来分隔类中的方法（method）定义。
可以使用额外的空行（尽量少）来分隔一组相关的函数。
在一系列相关的仅占一行的函数之间，空行也可以被省略（比如一组虚函数定义）。
在函数内使用空行（尽量少）使代码逻辑更清晰。

导入

​1. 导入应该分行写，而不是都写在一行，例如：​

# 分开写
import os
import sys

# 不要像下面一样写在一行
import sys, os

#也可以这样写
from subprocess import Popen, PIPE

​2. 导入应该写在代码文件开头，位于模块（module）注释和文档字符串之后，模块全局变量（globals）和常量（constants）声明之前。不同组的导入之间用空格隔开，顺序分组​

标准库imports
相关第三方imports
本地应用/库的特定imports

3.​推荐使用绝对（absolute imports），因为这样通常更易读​

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

​4. 当从一个包括类的模块中导入一个类时，通常可以这样写​

from myclass import MyClass
from foo.bar.yourclass import YourClass

​如果和本地命名的拼写产生了冲突，应当直接导入模块​

import myclass
import foo.bar.yourclass

模块级别的 __ 命名

​模块中的“双下滑线”（变量名以两个下划线开头，两个下划线结尾）变量。比如 ​__all__​ ， ​__author__​ ， ​__version__​ 等，应该写在文档字符串之后，除了 ​form __future__​ 导入的任何其它类型的引用语句之前。Python 要求模块中  的导入必须出现在除文档字符串之外的任何其他代码之前：​

"""模块的例子

模块的功能
"""

from __future__ import barry_as_FLUFL

__all__ = [a, b, c]
__version__ = 0.1
__author__ = Cardinal Biggles

import os
import sys

​表达式和语句中的空格​

​1. 方括号，圆括号和花括号之后​

推荐
spam(ham[1], eggs: 2)
反对
spam( ham[ 1 ],  eggs: 2  )

2.​参数最后一个逗号，和右括号之前​

推荐
foo = (0,)
反对
bar = (0, )

​3. 逗号，分号或冒号之前。​

推荐
if x == 4: print x, y; x, y = y, x
反对
if x == 4 : print x , y ; x , y = y , x

​注释​

• ​当注释和代码冲突时，优先考虑代码。当代码有改动时，一定要优先更改注释使其保持最新。​
• ​注释应该是完整的多个句子。​
• ​如果注释是一个短语或一个句子，其首字母应该大写。​
• ​除非开头是一个以小写字母开头的标识符（永远不要更改标识符的大小写）。​
• ​如果注释很短，结束的句号可以被忽略。​
• ​块注释通常由一段或几段完整的句子组成，每个句子都应该以句号结束。​
• ​你应该在句尾的句号后再加上 2 个空格。​
• ​使用英文写作，参考 Strunk 和 White 的《The Elements of Style》书籍。​
• ​来自非英语国家的 Python 程序员们：​

请使用英文来写注释，除非你 120% 确定你的代码永远不会被不懂你所用语言的人阅读到。

块注释

块注释一般写在对应代码之前，并且和对应代码有同样的缩进级别
块注释的每一行都应该以 # 和一个空格开头（除非该文本是在注释内缩进对齐的）
块注释中的段落应该用只含有单个 # 的一行隔开

行内注释

尽量少用行内注释
行内注释是和代码语句写在一行内的注释
行内注释应该至少和代码语句之间有两个空格的间隔，并且以 # 和一个空格开始
行内注释通常不是必要的，在代码含义很明显时甚至会让人分心

反对
x = x + 1                 # 变量 x 加 1
注释要有意义
x = x + 1                 # 边界补偿