2025.4.22

代码规范与评审检查表

1. C++代码规范

1.1 文件组织

• 头文件使用.h后缀，实现文件使用.cpp后缀
• 每个类应有自己的头文件和实现文件
• 文件命名采用小写字母加下划线，如my_class.h
• 头文件使用#pragma once防止重复包含

1.2 命名约定

• 类名使用大驼峰：MyClass
• 函数名使用小驼峰：myFunction
• 变量名使用小写加下划线：my_variable
• 常量全大写加下划线：MAX_SIZE
• 私有成员变量加m_前缀：m_member_variable

1.3 格式规范

• 使用4个空格缩进，不使用Tab
• 大括号换行风格：

  void function() {
      // code
  }
  

• 运算符前后加空格：a = b + c
• 每行不超过100个字符
• 函数参数过多时换行对齐：

  void longFunctionName(int param1, 
                       float param2,
                       const string& param3);
  

1.4 注释规范

• 文件头注释包含版权、作者、简要描述
• 类注释说明类的职责
• 函数注释说明功能、参数、返回值
• 复杂逻辑添加行注释
• 使用Doxygen风格：

  /**
   * @brief 计算两个数的和
   * @param a 第一个加数
   * @param b 第二个加数
   * @return 两数之和
   */
  

1.5 其他

• 优先使用const和constexpr
• 避免使用宏定义，改用constexpr或内联函数
• 使用nullptr而不是NULL
• 使用智能指针管理资源
• 禁止使用using namespace在头文件中

2. C++代码评审检查表

检查项	是/否	备注
代码是否符合命名规范？
函数长度是否过长（>50行）？
是否有重复代码可以提取？
是否处理了所有可能的错误情况？
指针和资源是否正确管理？
是否有内存泄漏风险？
是否有多线程安全问题？
接口设计是否合理？
是否有性能瓶颈？
单元测试是否覆盖所有分支？
注释是否准确且及时更新？
代码是否符合团队风格指南？
是否有未使用的变量或函数？
是否考虑了异常安全性？
日志和错误信息是否足够？

3. Python代码规范

3.1 文件组织

• 模块名使用小写字母加下划线：my_module.py
• 包名使用小写字母不加下划线：mypackage
• 每个模块应有__doc__字符串
• 导入顺序：标准库→第三方库→本地库，每组之间空一行

3.2 命名约定

• 模块名：小写加下划线my_module
• 类名：大驼峰MyClass
• 函数名：小写加下划线my_function
• 变量名：小写加下划线my_variable
• 常量：全大写加下划线MAX_SIZE
• 私有成员加单下划线前缀：_private_var

3.3 格式规范

• 使用4个空格缩进
• 每行不超过100个字符
• 运算符前后加空格：a = b + c
• 函数定义后空两行，类定义后空两行
• 函数参数过多时换行对齐：

  def long_function_name(
          param1, param2, param3,
          param4, param5):
      pass
  

3.4 注释规范

• 模块docstring说明模块功能
• 类docstring说明类职责
• 函数docstring说明功能、参数、返回值、异常
• 复杂逻辑添加行注释
• 使用Google风格docstring：

  def add(a, b):
      """计算两个数的和。
      
      Args:
          a: 第一个加数
          b: 第二个加数
          
      Returns:
          两数之和
          
      Raises:
          TypeError: 如果参数不是数字
      """
      return a + b
  

3.5 其他

• 优先使用Python内置函数和数据结构
• 避免使用from module import *
• 使用with管理资源
• 使用类型注解（Python 3.5+）
• 遵循PEP 8风格指南

4. Python代码评审检查表

检查项	是/否	备注
代码是否符合PEP 8规范？
是否有未使用的导入？
函数长度是否过长（>30行）？
是否有重复代码可以提取？
异常处理是否完备？
资源是否正确管理？
是否有潜在的竞态条件？
接口设计是否Pythonic？
是否有性能瓶颈？
单元测试是否覆盖所有分支？
docstring是否完整准确？
类型注解是否正确使用？
是否有魔法数字需要常量化？
日志和错误信息是否足够？
是否考虑了边界条件？

---

以上是我根据个人编程经验和常见问题建立的代码规范和评审检查表。在实际使用中，我会根据项目需求和团队规范进行适当调整，并定期回顾更新这些规范。