结论：不强制全员背熟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 是配置缺失、加载失败，还是根本没实现？这种模糊性是协作崩坏的起点。
立即学习“C++免费学习笔记（深入）”；
- 可能失败的函数返回
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 时，你能立刻看出谁改坏了契约。
