代码规范
Python代码规范
一、目标
统一代码风格、命名规范,增强代码可读性和可维护性,供日常开发工作中时参考,以提高团队协作的开发效率。
以下编程规范以Python为标准,其他语言可参考变通
二、编程规约
每一条规范前有【强制】或【推荐】的标签,可以针对性地根据自己需求遵守规范内容
2.1 项目规约
- 【强制】文件结构
1 | |- main (存放启动项目入口文件) |
- 【推荐】pylint代码检查
Pylint 是一个检查违反 PEP 8 规范和常见错误的库。它在一些流行的编辑器和 IDE 中都有集成,也可以单独从命令行运行。 Pylint主要的功能就是用于编码风格的检验,默认情况下 Pylint 会以 PEP-8为标准,如果写的代码不符合 PEP-8编码规范,它就会给你报错。可以通过修改 pylint 的配置文件,修改它检查的方式,从而使它遵守其他的编码规范,比如可以强行让变量名函数名都变成驼峰命名法。
前期项目demo的本地开发时不强制使用PYLINT等工具,但dev版本分支上传前需要检查
使用 Pylint 方便团队形成统一的编码规范。
1 | pip install pylint |
参考:Python代码规范:企业级代码静态扫描-代码规范、逻辑、语法、安全检查,以及代码规范自动编排(1)
- 【强制】Github
- 项目使用Github,前期封闭开发中切记不要将【private】改为【public】
- 相关代码文件或issue可以在飞书上记录
分支规范
我们制定分支规范,意在实现以下目标:
- 减少沟通成本:开发者可以很清晰地知道需要修改的代码位于哪个分支。
- 减少 bug 隐患:避免因分支合并导致 bug。
- 维护线上稳定:通过一定的流程规范,保证线上代码安全。
- 灵活:支持多版本同时开发、同时发布。
- 简洁:用最少的分支解决问题,避免反复创建、合并分支,节约操作时间。
主分支: master
主分支(master)用于存放最新的稳定版本。
标签的命名规范为:release-v版本号-日期(如 release-v0.0.1-20231010)
demo开发期 master 一般不动
开发分支: dev
dev 分支用于存放最新代码(可能包含未测试的代码),只有需要正式发布时才会合并到 prod 分支。
命名方式:dev-name,name为每个人的ID
构建分支: test
dev开发完毕后,同步至此分支,用于测试环境下的项目部署和功能调试
此外有些项目需要预编译(压缩、优化)才能发布上线,还需要build分支
生产分支: prod
经过开发与测试环境的检测通过后,合并到prod分支部署上线
master分支定期和prod进行同步
所有prod环境下的push和merge都要经过review
流程:
- 长期存在的就是 master 和 dev 分支
- 开发前,使用git pull/rebase等命令同步线上分支,避免改动冲突或丢失
- 根据自己的需要建立对应的分支dev-xx, 开发完成后合并到 test 分支
- 测试完成后没有问题 则合并到 dev 分支, 临时分支只留作本地使用
- 新功能发布需要从 dev 分支合并相应功能到 prod分支,生产环境下进行测试
- 测试结束后,合并进入 master 分支,再进行上线的部署发布
参考:
https://www.cnblogs.com/scajy/p/11514436.html
2.2 常量定义
- 不要使用中文拼音,尽量不要使用数字
- 尽量命名语义化
- 应该避免的名称
- 单字符名称, 除了计数器和迭代器
- 包/模块名中的连字符(-)
- 双下划线开头并结尾的名称(Python保留, 例如__init__)
2.3 编码风格
主要参考
行长度
- 每行不超过 120 个字符
- 例外:
- 长的导入模块语句
- 注释里的
URL
- 不要使用反斜杠连接行
括号
宁缺毋滥的使用括号
除非是用于实现行连接, 否则不要在返回语句或条件语句中使用括号. 不过在元组两边使用括号是可以的.
缩进
用4个空格来缩进代码
绝对不要用tab
, 也不要tab
和空格混用. 对于行连接的情况, 你应该要么垂直对齐换行的元素(见 行长度 部分的示例), 或者使用4空格的悬挂式缩进(这时第一行不应该有参数):
2.4 模块调用
Python
Python的模块可以简单理解为一个python文件。可以通过 import
语句导入。
一些规范:
- 模块名称要短、使用小写,并避免使用特殊符号,比如点(.) 和问号(?)
- 不推荐在模块名中使用下划线,而是使用子模块
from modu import *
的代码较难阅读而且依赖独立性不足,通常使用from modu import fun
或者import module
1 | #开源LIB |
2.5 注释
python注释也有自己的规范,可以起到一个备注的作用,团队合作的时候,个人编写的代码经常会被多人调用,为了让别人能更容易理解代码的通途,使用注释是非常有效的。
在说规范之前我们有必要先看以下Python的注释有哪些:
- 单行注释
- 多行注释
- 特殊注释
单行注释
以 # 开头, # 右边的所有东西都被当做说明文字,而不是真正要执行的程序,只起到辅助说明作用
示例代码如下:
1 | # 这是第一个单行注释 |
为了保证代码的可读性, # 后面建议先添加一个空格,然后再编写相应的说明文字
多行注释(块注释)
如果注释信息很多,一行无法显示,就可以使用多行注释:要在 Python 程序中使用多行注释,可以用一对连续的 三个 引号(单引号和双引号都可以)
所有类和函数都要有符合规范的注释,来说明其功能与参数
示例代码如下:
1 | """ |
特殊注释
- 必须是文件的第一行
- 必须以#!开头
- #!/usr/bin/env python告诉 LINUX/UNIX 去找到 python 的翻译器
1 | #!/usr/bin/env python |
2.6 函数调用
推荐使用 “with”语句管理文件接口
1 | with open("hello .txt") as hello_file. |
接口风格规范
2.7 异常处理
在基础模块的编写中,尽量使用try/except机制来捕捉异常,提高debug效率
基础使用
1 | import traceback |
注:一般我们会省略掉else和finally,视情况加入
Raise 语句
1 | # raise 语句允许强制发生指定的异常 |