Python代码的良好习惯

青春须早为，岂能长少年。这篇文章主要讲述Python代码的良好习惯相关的知识，希望能为你提供帮助。

?可读性才重要（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 要求模块中的导入必须出现在除文档字符串之外的任何其他代码之前：?