GD32 ARM单片机开发规范检查清单
以下检查清单基于您的编程规范制定,可用于代码审查和自检过程。通过逐项检查,确保代码符合项目规范要求。
代码审查流程 基础规范检查 功能实现检查 性能与安全检查 文档与注释检查 命名规范 格式规范 结构规范 功能完整性 API设计 错误处理 资源使用 安全措施 性能优化 代码注释 文档完整性
一、基础规范检查
1.1 文件组织
- 每个C源文件(.c)是否有对应的头文件(.h)
- 文件名是否使用小写字母并用下划线分隔
- 文件名是否清晰表达文件功能
- 头文件是否只包含接口声明(避免实现代码)
- 头文件是否使用防重复包含宏定义 (#ifndef/#define/#endif)
- 是否按照功能相关性组织文件内容
1.2 命名规范
- 全局变量是否添加_g后缀
- 静态局部变量是否添加_s后缀
- 指针变量是否使用xxxPtr命名
- 变量名是否使用驼峰形式(如pinNumber)
- 函数名是否使用下划线形式并以动词开头(如read_gpio_pin)
- 宏定义是否全部大写并使用下划线分隔
- 枚举类型是否使用_enumType_t后缀
- 结构体是否按规范定义(typedef struct xxx_struct xxx_t)
- 常用词是否使用规定的缩写(如buffer缩写为buff)
- 是否避免单字节变量命名(除循环变量i、j、k外)
1.3 格式规范
- 缩进是否统一为4个空格
- 相对独立的程序块之间是否加空行
- 操作符前后是否加空格(紧密关联的除外)
- 过长语句是否适当换行,并在低优先级操作符处划分
- 换行时操作符是否放在新行首
- 代码行长度是否合理(不超过80-120字符)
二、代码结构检查
2.1 函数设计
- 函数是否遵循单一职责原则
- 函数长度是否合理(非空非注释行不超过50行)
- 代码块嵌套深度是否不超过4层
- 内部函数是否使用static声明
- 外部接口函数是否有完整参数和返回值说明
- 参数顺序是否遵循输入在前输出在后的原则
- 参数较多时(>3个)是否考虑封装为结构体传递
- 函数是否有统一的错误返回机制(4000系列错误码)
2.2 模块化设计
- 代码是否按功能进行模块化组织
- 模块接口是否清晰明确
- 全局变量是否仅由一个模块负责修改
- 是否通过API函数访问模块内部数据(而非直接访问)
- 模块间依赖关系是否清晰合理
2.3 中断处理(补充项)
- 中断函数命名是否符合规范(模块名_IRQHandler)
- 中断服务程序是否尽可能短小(执行时间<10μs)
- 是否避免在中断中执行耗时操作(使用标志位模式)
- 中断中使用的共享变量是否添加volatile限定符
- 是否正确处理中断优先级设置
- 是否正确清除中断标志位
三、语法使用检查
3.1 数据类型使用
- 是否避免隐式类型转换
- 需要转换时是否使用显式转换并确保正确性
- 是否使用const定义常量(优先于宏定义)
- 对于指针参数,是否正确使用const限定符
- 结构体成员是否按照大小顺序排列(减少内存对齐填充)
3.2 语言特性使用
- 是否避免C语言危险函数(strcpy、gets等)
- 是否使用更安全的替代函数(strncpy、fgets等)
- switch-case语句是否有default分支
- 枚举类型switch是否处理所有可能值
- 是否避免使用goto语句(特殊情况除外)
- 是否合理使用内联函数(频繁调用的短小函数)
四、错误处理与验证检查
4.1 参数验证
- 函数入口处是否对输入参数进行有效性验证
- 对于指针参数,是否检查NULL
- 对于数值参数,是否检查范围有效性
- 对于枚举参数,是否检查是否为有效枚举值
4.2 错误处理
- 是否统一使用错误码机制
- 错误码是否按模块分类(如4000-4099系统级错误)
- 函数返回错误时,是否提供足够的错误信息
- 调用函数时,是否检查返回的错误码
- 是否有适当的错误日志记录机制
4.3 边界条件处理
- 是否考虑并处理边界条件(如0、最大值、溢出等)
- 数组操作是否检查索引越界
- 除法操作是否检查除数为零
- 内存操作是否检查分配失败情况
五、资源管理检查
5.1 内存管理
- 动态分配的内存是否配对释放(避免内存泄漏)
- 是否检查malloc等分配函数的返回值
- 堆内存使用是否合理(考虑嵌入式环境限制)
- 栈空间使用是否合理(避免栈溢出)
- 大数组是否定义为静态或全局变量(避免栈溢出)
5.2 外设资源管理
- 外设初始化和配置是否集中管理
- 共享资源是否有互斥访问机制
- 使用完毕的外设是否及时关闭或休眠(省电)
- 是否通过标准库函数而非直接访问寄存器操作外设
- DMA等高级功能是否正确配置和管理
5.3 低功耗管理(补充项)
- 是否关闭非必要外设时钟以节省功耗
- 是否合理配置和使用低功耗模式
- 是否正确配置唤醒源
- 是否在进入低功耗前保存必要状态
- 是否在唤醒后正确恢复系统状态
六、性能优化检查
6.1 算法优化
- 是否选择了合适的算法(考虑时间和空间复杂度)
- 循环中是否避免重复计算不变量
- 是否减少不必要的函数调用(特别是在关键路径)
- 是否使用查表法代替复杂计算(适用情况下)
- 是否合理使用位操作优化算法
6.2 硬件特性利用
- 是否利用了硬件加速功能(如硬件乘法器)
- 是否使用DMA减轻CPU负担
- 是否合理配置Cache(如有)
- 是否利用GD32特有的硬件特性优化性能
- 关键计算是否考虑使用汇编优化
七、文档与注释检查
7.1 代码注释
- 文件头部是否有详细注释(包括功能、作者、日期等)
- 函数声明处是否有详细注释(参数、返回值、功能)
- 复杂算法是否有详细解释
- 重要变量是否有说明注释
- 注释是否放在代码上方相邻位置或右方(不放在下方)
- 对于可能为0的运算结果是否添加// maybe 0注释
7.2 版本管理
- 代码修改是否有修改记录(日期、作者、内容)
- 是否记录了版本号和对应功能
- 移除或注释代码是否说明原因
八、硬件抽象层检查(补充项)
8.1 HAL设计
- 是否实现了硬件抽象层接口
- 硬件依赖代码是否集中在特定文件中
- 是否使用函数指针结构体方式实现硬件抽象
- 应用代码是否通过抽象接口而非直接访问硬件
- 不同硬件平台切换是否仅需修改底层实现
九、编译器与工具链检查
9.1 编译器特性使用
- 是否避免使用非标准扩展(除非必要)
- 是否正确使用预处理指令(#if/#ifdef等)
- 是否使用pragma指令控制特定编译行为(必要时)
- 是否使用__attribute__等ARM特有特性优化代码
9.2 编译警告处理
- 代码是否能以高警告级别编译通过(-Wall -Werror)
- 是否修正了所有隐式声明警告
- 是否处理了所有未使用变量警告
- 是否处理了所有可能的类型转换警告
- 是否处理了结构体填充警告
使用说明
- 在每次代码审查或提交前使用此清单检查代码
- 对于每个检查项,标记为"是"表示符合规范,"否"表示需要修改
- 对于"否"项,记录需要修改的内容和位置
- 持续更新此清单以适应项目需求变化
- 建议将此清单集成到CI/CD流程中,自动化部分检查项
优先级分类
- 必须项:影响代码正确性和安全性的项目(如错误处理、资源管理)
- 重要项:影响代码可维护性和效率的项目(如命名规范、注释)
- 建议项:有助于提高代码质量但不影响功能的项目(如某些优化)
根据项目阶段和资源情况,可以选择优先关注必须项和重要项。