GD32 ARM单片机开发规范检查清单
以下检查清单基于您的编程规范制定，可用于代码审查和自检过程。通过逐项检查，确保代码符合项目规范要求。
一、基础规范检查
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流程中，自动化部分检查项
优先级分类
- 必须项：影响代码正确性和安全性的项目（如错误处理、资源管理）
- 重要项：影响代码可维护性和效率的项目（如命名规范、注释）
- 建议项：有助于提高代码质量但不影响功能的项目（如某些优化）
根据项目阶段和资源情况，可以选择优先关注必须项和重要项。
)
