73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
# C++ 代码风格（Code Style）
|
||
|
||
本章节规定 C++（C++23，含 Modules）代码的结构与格式约定。
|
||
|
||
## 1. 文件与组织
|
||
|
||
### 1.1 目录建议（项目落地）
|
||
|
||
推荐将 C++ 代码放在独立目录（多语言项目便于隔离规则与工具）：
|
||
|
||
```txt
|
||
cpp/
|
||
include/ # 对外头文件（如项目仍使用头文件边界）
|
||
src/ # 实现文件与 module 实现单元
|
||
modules/ # module interface / partition（如使用 modules）
|
||
tests/ # （可选）测试
|
||
CMakeLists.txt
|
||
```
|
||
|
||
若项目不采用 `cpp/` 根目录，也应保持 include/src/modules 分层清晰。
|
||
|
||
### 1.2 文件扩展名约定
|
||
|
||
- 头文件：`.h`（Google 风格；若项目已统一 `.hpp`，以项目既有为准）
|
||
- 源文件：`.cc`（优先；`main` 入口建议使用 `main.cc`；若项目已统一 `.cpp`，以项目既有为准）
|
||
- Module Interface Unit：`.cppm`（推荐统一）
|
||
- Module Partition：`.cppm`（在文件名中体现分区，例如 `foo_part.cppm`）
|
||
|
||
### 1.3 Modules 约定（C++23）
|
||
|
||
- Module 名称建议使用“点分层级”组织，且每一段使用 `lower_snake_case`：
|
||
- 示例：`my_project.net.http`
|
||
- 文件路径与 module 名建议可映射（便于检索）：
|
||
- `cpp/modules/my_project/net/http.cppm` → `export module my_project.net.http;`
|
||
- 避免在同一模块内混用“头文件边界”和“模块边界”造成可见性混乱；对外 API 优先通过 `export` 暴露。
|
||
- 工程约束：新增/删除/重命名 `.cppm`（或变更 `export module ...`）时，必须同步更新构建系统的模块清单（例如 CMake 的 `target_sources(FILE_SET CXX_MODULES ...)`），否则容易出现“本地能编、CI/他人机器不能编”的漂移。
|
||
|
||
## 2. 格式（Formatting）
|
||
|
||
### 2.1 clang-format（必选）
|
||
|
||
- 本仓库/标准默认：`clang-format` + Google 风格。
|
||
- 建议在项目根目录提供 `.clang-format` 并纳入 CI/本地钩子。
|
||
- 列宽建议与本 Playbook 其他语言保持一致：默认 100（可按项目调整，但要全仓一致）。
|
||
- 模板：`templates/cpp/.clang-format`（参考 `tsl-devkit/lsp-server/.clang-format` 并做了最小化泛化）。
|
||
|
||
### 2.2 通用格式约定
|
||
|
||
- 缩进使用空格，单次缩进 4 空格（Google）。
|
||
- 不做“空格对齐排版”（避免 diff 噪音），用缩进表达结构。
|
||
- 头文件 include 顺序建议（从上到下）：
|
||
1. 本文件对应头（如有）
|
||
2. C 标准库 / C++ 标准库
|
||
3. 第三方库
|
||
4. 项目内其他头/模块导入
|
||
|
||
## 3. 头文件与可见性
|
||
|
||
- 头文件应可被独立 include（自包含）。
|
||
- 对外接口放在 `include/`，实现细节放 `src/`。
|
||
- 避免在头文件中引入沉重依赖；可用前置声明或 PImpl（按项目需要）。
|
||
|
||
## 4. 错误处理与资源管理
|
||
|
||
- 默认使用 RAII 管理资源；避免裸 `new/delete`。
|
||
- 禁止吞异常/忽略错误；失败路径必须可观测（返回值/异常/日志其一或按项目约定）。
|
||
|
||
## 5. Windows 支持
|
||
|
||
- 本规范假设 **不做原生 Windows 开发环境支持**；Windows 产物通过 **Linux 上的 Clang 交叉编译工具链**获得（工具链路径/三元组等由项目的 Conan profile 或 toolchain 文件定义）。
|
||
- 如需条件编译，优先用标准特性检测与最小化条件编译，并写清动机（例如 ABI/平台差异）。
|
||
- 对路径、换行、编码、大小写敏感等行为要明确约束并在文档/测试中覆盖。
|