Python代码规范

  • 更新日期:2021-5-11

注释

1.单行函数注释

  • 示例
# 【fish】获取原始数据模板列表 -2021/3/29
def get_tmpls(query, status):
    # 获取符合条件模板信息
    tmpls_info = self._tmpl.get_tmpls_data()
    if not tmpls_info:
        # 没有模板信息,返回错误
        return _SERVERS_ERR["NO_TMPLS_DATA"]
    pass
  • 说明
    • 该注释仅适用于对简单函数或方法进行说明,格式:”【开发者】函数说明 -最近更新日期

2.多行函数注释

  • 示例
"""
【fish】获取原始数据模板列表 -2021/3/29
- 获取前需先设置模板ID
@Params
    :query:dict: 查询条件
        - tmpl_name:str: 需要查询的模板名称
    :status:int: 模板启用状态
@Return
    :list<TemplateModel>: 返回模板对象列表
@Errors:
    - ValueError: 参数校验错误
    - TypeError: 参数类型错误
"""
def get_tmpls(query, status):
    # 获取符合条件模板信息
    tmpls_info = self._tmpl.get_tmpls_data()
    if not tmpls_info:
        # 没有模板信息,返回错误
        return _SERVERS_ERR["NO_TMPLS_DATA"]
    pass
  • 说明
    • 首行注释:对函数或方法进行简要说明,格式:”【开发者】函数说明 -最近更新日期
    • 次行注释:可对首行注释进一步进行说明,允许多行,但每行注释前需使用:”-“ 符号进行标识
    • 参数注释:开头统一使用”@Params“进行标识,具体参数说明切换至下一行开始并进一步缩进,具体参数说明的格式:”:参数名:参数类型: 参数说明“;同时,对于单个参数,还可以对其内部子参数进一步说明,需换至下一行开始并进一步缩进,说明格式:”- 子参数名:子参数类型: 子参数说明
    • 返回值注释:开头统一使用”@Return“进行标识,具体返回值说明切换至下一行开始并进一步缩进,具体说明格式:”:返回值类型: 返回值说明
    • 错误异常注释:开头统一使用”@Errors“进行标识,具体错误异常说明切换至下一行开始并进一步缩进,具体说明格式:”- 错误异常类型: 错误异常说明

3.单行类注释

  • 示例
# 【fish】原始数据类 -2021/3/29
class RawData:

    def __init__(self):
        pass
  • 说明
    • 该注释仅适用于对简单类进行说明,格式:”【开发者】类名 -该类创建日期

4.多行类注释

  • 示例
class RawData:

    """
    【fish】原始数据类 -2021/3/29
    - 用于对原始数据模块校验的处理
    - 原始数据基本属性的封装 
    """

    def __init__(self):
        pass
  • 说明
    • 首行注释:固定介绍,格式:”【开发者】类名 -该类创建日期
    • 次行注释:可对类进一步进行说明,允许多行,但每行注释前需使用:”-“ 符号进行标识

空行

1.函数之间预留行数

  • 示例
def get_rdata():
    pass

def get_tmpls():
    pass

class RawData:

    def get(self):
        pass

    def set(self):
        pass
  • 说明
    • 统一预留一行

2.类之间预留行数

  • 示例
class RawData:
    pass


class Tmpl:
    pass
  • 说明
    • 统一预留两行

命名风格

1.类命名


2.方法名、参数名、成员变量、局部变量命名

  • 示例
local_value = 1

def get_http_msg(var_name): 
    inner_var = var_name
  • 说明
    • 统一使用PYTHON标准命名方式

3.常量命名


4.包命名

  • 示例
from service.stl.raw_data import RawDataTemplate
  • 说明
    • 包名统一使用小写,点分隔符之间尽量保证仅有一个自然语义的英语单词
    • 包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式

5.单词缩写

  • 示例
"""6个字母以下不简写"""
# eg:raw  -->  raw

"""7-12个字母以下缩写至不超过6个单词"""
# eg:template --> tmpl
# eg:information --> info
  • 说明
    • 英语单词缩写需要符合基本的英文规范
    • 若项目定义了“接口文档或数据字典命名规范”,缩写需与该规范保持一致
    • 杜绝完全不规范的缩写,避免望文不知义

6.枚举类

  • 示例
from enum import Enum

class AccountEnum(Enum):
    ALIPAY = 1
    CREDIT_CARD = 2
  • 说明
    • 枚举类名带上 Enum 后缀
    • 枚举成员名称需要全大写,单词间用下划线隔开

7.各层命名规约



8.其他规则

  • 示例
# eg: 常量与变量的命名
start_time, work_queue, name_list, TERMINATED_THREAD_COUNT = None, None, None, None

# eg: 设计模式
class OrderFactory:
    pass
  • 说明
    1. 在常量与变量的命名时,表示类型的名词放在词尾,以提升辨识度
    2. 如果模块、接口、类、方法使用了设计模式,在命名时需体现出具体模式

函数

1.函数命名

  • 示例
def get_tmpls():
    pass

def get_tmpl_by_id():
    pass
  • 说明
    • 基本格式:”动词 + 名词 + 修饰或条件
    • 上面格式中的:”动词 + 名词“ 为必须组成部分,”修饰或条件“ 为可选部分

2.函数有效行数

  • 说明
    • 建议单个简单函数体或方法体内有效代码行数不超过20行
    • 建议单个复杂函数体或方法体内有效代码行数不超过40行
    • 非强制要求

应用分层

1.分层说明



2.分层异常处理规约



3.分层领域模型规约


设计规约

  1. 【强制】存储方案和底层数据结构的设计获得评审一致通过,并沉淀成为文档。
    说明:有缺陷的底层数据结构容易导致系统风险上升,可扩展性下降,重构成本也会因历史数据迁移和系
    统平滑过渡而陡然增加,所以,存储方案和数据结构需要认真地进行设计和评审,生产环境提交执行后,
    需要进行 double check。
    正例:评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发
    展、表或字段之间的辩证关系、字段名称、字段类型、索引等;数据结构变更(如在原有表中新增字段)
    也需要进行评审通过后上线

  2. 【强制】在需求分析阶段,如果与系统交互的 User 超过一类并且相关的 User Case 超过 5 个,使用用例图来表达更加清晰的结构化需求。

  3. 【强制】如果某个业务对象的状态超过 3 个,使用状态图来表达并且明确状态变化的各个触发条件。
    说明:状态图的核心是对象状态,首先明确对象有多少种状态,然后明确两两状态之间是否存在直接转换
    关系,再明确触发状态转换的条件是什么。
    正例:淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两
    种状态之间是不可能有直接转换关系的。

  4. 【强制】如果系统中某个功能的调用链路上的涉及对象超过 3 个,使用时序图来表达并且明确各调用环节的输入与输出。
    说明:时序图反映了一系列对象间的交互与协作关系,清晰立体地反映系统的调用纵深链路。

  5. 【强制】如果系统中模型类超过 5 个,并且存在复杂的依赖关系,使用类图来表达并且明确类之间的关系。
    说明:类图像建筑领域的施工图,如果搭平房,可能不需要,但如果建造蚂蚁 Z 空间大楼,肯定需要详细
    的施工图。

  6. 【强制】如果系统中超过 2 个对象之间存在协作关系,并且需要表示复杂的处理流程,使用活动图来表示。
    说明:活动图是流程图的扩展,增加了能够体现协作关系的对象泳道,支持表示并发等。

  7. 【推荐】系统架构设计时明确以下目标:
    ⚫ 确定系统边界。确定系统在技术层面上的做与不做。
    ⚫ 确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。
    ⚫ 确定指导后续设计与演化的原则。使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化。
    ⚫ 确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。