35 lines
1.4 KiB
Markdown
35 lines
1.4 KiB
Markdown
# 代码质量（Code Quality）
|
||
|
||
本文件定义代理对代码质量的最低要求与审查清单（C++）。
|
||
|
||
## 1. 总体要求
|
||
|
||
- C++ 代码遵守 `docs/cpp/code_style.md` 与 `docs/cpp/naming.md`（在目标项目中通常 vendoring 到标准快照路径）。
|
||
- 统一使用 `clang-format`（Google 基线）保持格式一致；不要手工“对齐排版”制造 diff 噪音。
|
||
- 改动聚焦目标；避免“顺手重构”。
|
||
- API 变更要显式说明影响与迁移方式。
|
||
- 涉及三方依赖（例如 Conan）的改动必须说明动机、替代方案与影响面；默认不“顺手升级依赖”。
|
||
- 涉及 C++ Modules 的改动（`.cppm` 或 `export module` 变更）必须同步更新构建系统的模块清单与相关 target 配置。
|
||
|
||
## 2. 可读性
|
||
|
||
- 复杂逻辑拆分为具名函数/类型；避免深层嵌套与重复代码。
|
||
- 必要注释解释“为什么”而不是“做什么”。
|
||
|
||
## 3. 错误处理与资源管理
|
||
|
||
- 默认使用 RAII；避免裸 `new/delete`。
|
||
- 失败路径必须可观测（返回值/异常/日志其一或按项目约定）。
|
||
|
||
## 4. 复杂度与规模
|
||
|
||
- 单函数尽量 ≤ 80 行；超过应说明原因或拆分（可按项目调整）。
|
||
- 单次 PR 尽量小步提交，便于 review。
|
||
|
||
## 5. Review 清单
|
||
|
||
- 是否有无关改动？
|
||
- 是否保持模块内风格一致？
|
||
- 是否引入不必要的复杂度/依赖？
|
||
- 是否有最小验证（构建/冒烟）步骤？
|