PEP8 编码规范, 及开发中的?一些惯例例和建议

Posted 2021-01-01 sharepy

首先看下面这段代码，是否满足编码规范

 1 from django.conf import settings 
 2 from user.models import * 
 3 import sys, os 
 4 mod=0xffffffff
 5 deffoo (a,b=123):
 6     c={ ‘x‘ : 111 , ‘y‘ : 222 }#定义?一个字典 d=[ 1 , 3,5 ]
 7 return a,b , c
 8 
 9 def bar(x):
10     if x%2==0 : return True

 PEP8编码规范修改后

 1 import os
 2 import sys
 3 
 4 from django.conf import settings
 5 from django.core import xxx
 6 
 7 from user.models import User
 8 from user.models import Perm
 9 
10 MOD = 0xffffffff
11 
12 
13 def foo(a, b=123):
14     ‘‘‘this is foo‘‘‘
15     c = {‘x‘: 111, ‘y‘: 222}
16     d = [1, 3, 5]
17     return a, b, c
18 
19 
20 def bar(x):
21     ‘‘‘this is bar‘‘‘
22     if x % 2 == 0:
23         return True

- 为什么要有编码规范

编码是给人看的还是给机器看的？
美观是重点吗？
1. 美观
2. 可读性
3. 可维护性
4. 健壮性
团队内最好的代码状态: 所有人写出的代码像一个人写出来的

- 代码编排:

* 缩进 4 个空格, 禁止空格与 Tab 混用
* 行长 80 字符: 防止单行逻辑过于复杂

- import

不要使用 `from xxx import *`
顺序

1. 标准库
2. 第三方库
3. 自定义库

单行不要 import 多个库

模块内用不到的不要去 import

- 空格

 `: ,` 后面跟一个空格, 前面无空格 (行尾分号后无空格)
二元操作符前后各一个空格, 包括以下几类:

1. 数学运算符: `+ - * / // = & | `
2. 比较运算符: `== != > < >= <= is not in`
3. 逻辑运算符: `and or not`
4. 位运算符: `& | ^ << >>`

　　当 `=` 用于指示关键字参数或默认参数值时, 不要在其两侧使用空格

- 适当添加空行

* 函数间: 顶级函数间空 2 行, 类的方法之间空 1 行
* 函数内: 同一函数内的逻辑块之间, 空 1 行
* 文件结尾: 留一个空行 (Unix 中 是文件的结束符)

- 注释

* 忌: 逐行添加注释, 没有一个注释
* 行尾注释: 单行逻辑过于复杂时添加
* 块注释: 一段逻辑开始时添加
* 引入外来算法或者配置时须在注释中添加源连接, 标明出处
* 函数、类、模块尽可能添加 `docstring`

- 命名

* 好的变量名要能做到“词能达意”
* 除非在 lambda 函数中, 否则不要用 **单字母** 的变量名 (即使是 lambda 函数中的变量名也应该尽可能的有意义)
* 包名、模块名、函数名、方法、普通变量名全部使用小写, 单词间用下划线连接
* 类名、异常名使用 CapWords (首字母大写) 的方式, 异常名结尾加 `Error` 或 `Wraning` 后缀
* 全局变量尽量使用大写, 一组同类型的全局变量要加上统一前缀, 单词用下划线连接
* 函数名必须有动词, 最好是 do_something 的句式, 或者 somebody_do_something 句式

- 语意明确、直白

* `not xx in yy` *VS* `xx not in yy`
* `not a is b` *VS* `a is not b`

- 程序的构建

* 函数是模块化思想的体现
* 独立的逻辑应该抽离成独立函数，让代码结构更清晰，可复用度更高
* **一个函数只做一件事情, 并把这件事做好**
* **大的功能用小函数之间灵活组合来完成**
* 避免编写庞大的程序, **“大” 意味着体积庞大, 逻辑复杂甚至混乱**

- 自定义的变量名、函数名不要与标准库中的名字冲突

- pip install pycodestyle pylint flake8 autopep8