代码规范|Coding Conventions
PEP8
gitbook
编码|Coding
如无特殊情况, 文件一律使用UTF-8编码。
如无特殊情况, 文件头部必须加入#-*-coding:utf-8-*-
标识。
缩进|Indentation
统一使用4个空格进行缩进。
-
第二行缩进到括号的起始处
1
2
3
4# Correct:
# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
var_three, var_four)
Wrong:
Arguments on first line forbidden when not using vertical alignment.
foo = long_function_name(var_one, var_two,
var_three, var_four)
1 | - 第二行缩进4个空格,适用于起始括号就换行的情形。使用反斜杠\换行,二元运算符+ .等应出现在行末;长字符串也可以用此法换行。 |
-
禁止复合语句,即一行中包含多个语句
1
2
3
4# 正确的写法
do_first()
do_second()
do_third()
不推荐的写法
do_first();do_second();do_third();
1 | - if/for/while一定要换行: |
最大行宽|Maximum Line Length
每行代码尽量不超过80个字符(在特殊情况下可以略微超过80,但最长不得超过120)
理由:
- 这在查看side-by-side的diff时很有帮助
- 方便在控制台下查看代码
- 太长可能是设计有缺陷
引号|String Quotes
In Python, single-quoted strings and double-quoted strings are the same. This PEP does not make a recommendation for this. Pick a rule and stick to it. When a string contains single or double quote characters, however, use the other one to avoid backslashes in the string. It improves readability.
For triple-quoted strings, always use double quote characters to be consistent with the docstring convention in PEP 257.
简单说,自然语言使用双引号,机器标示使用单引号,因此 代码里 多数应该使用 单引号
- 自然语言 使用双引号 “…”
- 例如错误信息;很多情况还是unicode,使用u"你好世界"
- 机器标识 使用单引号 ‘…’ 例如dict里的key
- 正则表达式 使用原生的双引号 r"…"
- 文档字符串(docstring) 使用三个双引号 “”“…”“”
空行|Blank Lines
-
模块级函数和类定义之间空两行; Surround top-level function and class definitions with two blank lines.
-
类成员函数之间空一行;Method definitions inside a class are surrounded by a single blank line.
-
可以使用多个空行分隔多组相关的函数
-
函数中可以使用空行分隔出逻辑相关的代码
1
2
3
4
5
6
7class A:
def __init__(self):
pass
def hello(self):
pass
def main():
pass
1 |
|
-
import语句应该使用 absolute import
1
2# 正确的写法
from foo.bar import Bar
不推荐的写法
from …bar import Bar
1 | - import语句应该放在文件头部,置于模块说明及docstring之后,于全局变量之前; |
-
导入其他模块的类定义时,可以使用相对导入
1
from myclass import MyClass
-
如果发生命名冲突,则可使用命名空间
1
2import bar
import foo.bar
bar.Bar()
foo.bar.Bar()
1 | ## 空格|Whitespace |
-
函数的参数列表中逗号分隔符之后要有空格
1
2
3# Correct:
def complex(real, imag):
pass
Wrong:
def complex(real,imag):
pass
1 | - 函数的参数列表中,默认值等号两边不要添加空格 |
-
左括号之后,右括号之前不要加多余的空格
1
2
3
4
5
6
7
8# Correct:
spam(ham[1], {eggs: 2})
foo = (0,)
spam(1)
# Wrong:
spam( ham[ 1 ], { eggs: 2 } )
bar = (0, )
spam (1) -
字典对象的左括号之前不要多余的空格
1
2
3
4# Correct:
dct['key'] = lst[index]
# Wrong:
dct ['key'] = lst [index] -
不要为对齐赋值语句而使用的额外空格
1
2
3
4
5
6
7
8# Correct:
x = 1
y = 2
long_variable = 3
# Wrong:
x = 1
y = 2
long_variable = 3注释|Comments
在代码的关键部分(或比较复杂的地方), 能写注释的要尽量写注释
比较重要的注释段, 使用多个等号隔开, 可以更加醒目, 突出重要性
1 | app = create_app(name, options) |
块注释|Block Comments
“#”号后空一格,段落件用空行分开(同样需要“#”号)
1 | # 块注释 |
行注释|Inline Comments
至少使用两个空格和语句分开,注意不要使用无意义的注释。Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.
1 | # Corrent: |
文档注释|Documentation Strings
作为文档的Docstring一般出现在模块头部、函数和类的头部,这样在python中可以通过对象的__doc__对象获取文档. 编辑器和IDE也可以根据Docstring给出自动提示.
docstring的规范在PEP257中有详细描述,其中最其本的两点:
-
所有的公共模块、函数、类、方法,都应该写docstring。私有方法不一定需要,但应该在def后提供一个块注释来说明。
-
docstring的结束""“应该独占一行,除非此docstring只有一行。文档注释以 “”” 开头和结尾, 首行不换行, 如有多行, 末行必需换行, 以下是Google的docstring风格示例
1
2# -*- coding: utf-8 -*-
"""Example docstrings.
This module demonstrates documentation as specified by the Google Python Style Guide
_. Docstrings may extend over multiple lines. Sections are created
with a section header and a colon followed by a block of indented text.
Example:
Examples can be given using either the Example
or Examples
sections. Sections support any reStructuredText formatting, including
literal blocks::
$ python example_google.py
Section breaks are created by resuming unindented text. Section breaks
are also implicitly created anytime a new section starts.
“”"
1 | 不要在文档注释复制函数定义原型, 而是具体描述其具体内容, 解释具体参数和返回值等 |
对函数参数、返回值等的说明采用numpy标准, 如下所示
1 | def func(arg1, arg2): |
文档注释不限于中英文, 但不要中英文混用
文档注释不是越长越好, 通常一两句话能把情况说清楚即可
模块、公有类、公有方法, 能写文档注释的, 应该尽量写文档注释
命名规则|Naming Conventions
- 应避免使用小写字母l(L),大写字母O(o)或I(i)单独作为一个变量的名称,以区分数字1和0
- 尽量避免单字符变量名
- 包和模块使用全小写命名,尽量不要使用下划线
- 类名使用CamelCase命名风格,内部类可用一个下划线开头
- 函数使用下划线分隔的小写命名
- 当参数名称和Python保留字冲突,可在最后添加一个下划线,而不是使用缩写或自造的词
- 常量使用以下划线分隔的大写命名
Type | Naming Convention | Examples |
---|---|---|
Function | Use a lowercase word or words. Separate words by underscores to improve readability. | function, my_function |
Variable | Use a lowercase single letter, word, or words. Separate words with underscores to improve readability. | x, var, my_variable |
Class | Start each word with a capital letter. Do not separate words with underscores. This style is called camel case. | Model, MyClass |
Method | Use a lowercase word or words. Separate words with underscores to improve readability. | class_method, method |
Constant | Use an uppercase single letter, word, or words. Separate words with underscores to improve readability. | CONSTANT, MY_CONSTANT, MY_LONG_CONSTANT |
Module | Use a short, lowercase word or words. Separate words with underscores to improve readability. | module.py, my_module.py |
Package | Use a short, lowercase word or words. Do not separate words with underscores. | package, mypackage |
程序设计规范|Programming Recommendations
避免’裸代码’
尽量不要直接将代码写在模块的顶层中,在执行主程序前应该总是检查 if name == ‘main’ , 这样当模块被导入时主程序就不会被执行.
1 | # 不推荐的写法(裸代码) |
所有的顶级代码在模块导入时都会被执行. 要小心不要去调用函数, 创建对象, 或者执行那些不应该在使用pydoc时执行的操作.
字符串|String
尽量不要用+号拼接字符串, 使用%s模板或join拼接
1 | # 不推荐的写法 |
列表和字典|List&Dict
在不复杂的情况下, 尽量多用列表生成式, 可以使代码更加清晰
注意: 复杂情况下不适用, 列表生成式过复杂反而会导致阅读和调试困难
1 | # 不推荐的写法 |
尽量使用map和filter等内置函数, 而不是自己去写循环
1 | numbers = [1, 2, 6, 9, 10 ...] |
正则表达式|Regular Expression
正则表达式前一律加r
1 | regex_phone = re.compile(r'(13\d|14[57]|15[^4,\D]))$') |
正则表达式使用前尽量先编译好
1 | # 不推荐的写法, 不要使用未编译的正则 |