结论：不强制全员背熟CppCoreGuidelines，但必须落地命名、资源管理、接口契约三类硬性约束。命名需带作用域语义，资源必须RAII化，接口须显式声明异常与空值语义。

直接说结论：不强制要求全员背熟 CppCoreGuidelines，但必须落地其中 3 类硬性约束——命名、资源管理、接口契约，否则代码会快速退化为“多人维护的单人代码”。

命名必须带作用域语义，禁止裸名 data、value、list

这类名字在 PR 里出现一次，就增加一次理解成本。团队不是靠猜变量用途协作的。

• std::vector<:string> users 比 std::vector<:string> data 明确 10 倍
• 函数参数不用 int x，而用 int user_id 或 int timeout_ms，哪怕只用一次
• 类内私有成员加后缀 _（如 name_），避免与参数/局部变量同名时意外遮蔽
• 枚举项必须带前缀：LogLevel::Warning 而非裸 Warning，防止跨头文件冲突

所有资源必须 RAII 化，禁用裸 new/delete 和 malloc/free

不是“能跑就行”，而是“没人敢动这块逻辑”——裸指针会让任何修改都变成雷区。

• 动态数组一律用 std::vector 或 std::unique_ptr，禁用 T* p = new T[n]
• 文件句柄用 std::fstream，网络 socket 封装进 RAII 类（哪怕只有构造/析构两行）
• 第三方 C API 返回的资源（如 sqlite3_stmt*），必须立即包进自定义 RAII 类或 std::unique_ptr 的自定义 deleter
• 例外仅限于性能关键路径且经 profiler 验证——但需加 // NOLINTNEXTLINE(cppcoreguidelines-owning-memory) 并附简短注释

函数接口必须显式声明异常行为和空值语义，禁用隐式 nullptr 返回

调用方看到 get_config()，无法判断它返回 nullptr 是配置缺失、加载失败，还是根本没实现？这种模糊性是协作崩坏的起点。

• 可能失败的函数返回 std::optional（成功/无值）或 std::expected（

  

  C++23，或用 absl::StatusOr）
• 禁止返回裸指针表示“可选”，除非是已知非空的观察者（此时用 T* 并注释 // not null）
• 参数中若允许空，必须用 std::optional 或 std::string_view（而非 const std::string& + 默认空字符串）
• 所有 public 函数头注释必须写明：/// @throws std::runtime_error on I/O failure 或 /// @returns nullopt if config file not found

class ConfigLoader {
public:
    std::optional load(const std::filesystem::path& path);
    // 不是 Config* load(...)，也不是 bool load(..., Config& out)
};
// 调用侧清晰、安全、无需查文档猜行为
if (auto cfg = loader.load("config.json")) {
use(*cfg);
} else {
log_warning("config missing, using defaults");
}

最难的不是写对某一行，而是让所有人持续识别出“这里该用 std::optional 还是 std::expected”，或者“这个 _ 到底该不该加”。规范的生命力不在文档页数，而在每次 git blame 时，你能立刻看出谁改坏了契约。