代码规范与风格：Google C++ Style Guide 核心要点

聊到大型C++项目，我第一个想说的就是代码规范。你可能觉得这玩意儿有点虚，不就是个格式问题吗？嗯，我在早期带团队时也这么想。直到有一次，我们接手了一个遗留系统，代码风格五花八门——有人用驼峰，有人用下划线，缩进从2格到8格都有。结果呢？代码审查变成了吵架大会，合并冲突天天有。从那以后，我彻底服了：没有规范的项目，迟早要还债。

Google C++ Style Guide 核心要点

Google的规范我用了很多年，说实话，它并不完美，但胜在全面。我挑几个最关键的说说。

命名规范

命名这事儿，说白了就是让代码能自解释。Google规范里这几条我特别认同：

• 文件名：小写+下划线，比如 http_client.cc、user_manager.h。我个人习惯避免用大写字母，因为跨平台时大小写敏感问题很烦人。
• 类型名：大驼峰，比如 class HttpConnection、struct UserInfo。注意，结构体也走这个规则。
• 变量名：小写+下划线，比如 int user_count、std::string file_path。类成员变量末尾加下划线，比如 user_count_。这个习惯我一开始觉得别扭，后来发现它真的能一眼区分局部变量和成员变量。
• 函数名：大驼峰，比如 void ParseRequest()。访问器（getter/setter）和变量名一致，比如 int user_count() 和 void set_user_count(int count)。
• 常量/枚举：k开头+大驼峰，比如 const int kMaxRetryCount = 3、enum Color { kRed, kGreen, kBlue }。

注释规范

注释这事儿，我见过两个极端：一种是完全不写，另一种是每行都写。其实都不对。Google规范里强调：注释应该解释「为什么」，而不是「是什么」。

举个例子：

// 错误：注释在重复代码
// 将用户计数加1
user_count_++;

// 正确：注释解释了业务逻辑
// 用户完成注册后，需要立即更新计数，否则后续的欢迎邮件会发错
user_count_++;

另外，文件头部的版权声明和作者信息，我建议保留。虽然现在有Git blame，但大型项目里，一个文件可能被几十个人改过，头部注释能快速定位原始作者。

格式规范

格式问题，我强烈建议交给工具。手动对齐缩进？那是上个世纪的做法。Google规范里对缩进、空格、空行都有详细规定，但你不必死记硬背——用Clang-Format自动格式化就好。

Clang-Format 配置

Clang-Format是我最爱的工具之一。你想想看，一个团队几十个人，每个人IDE的自动格式化设置都不一样，怎么办？用统一的 .clang-format 文件，一劳永逸。

下面是我常用的配置，基于Google风格，但做了一些微调：

BasedOnStyle: Google
IndentWidth: 4
AccessModifierOffset: -4
ColumnLimit: 120
AllowShortFunctionsOnASingleLine: Inline
BreakBeforeBraces: Attach
PointerAlignment: Left
DerivePointerAlignment: false

这里有几个点我想强调：

• 缩进宽度：Google默认是2格，但我个人习惯4格。2格在嵌套深的时候容易看花眼，4格更清晰。当然，这取决于团队偏好。
• 列宽限制：Google默认80列，我放宽到120。现在显示器都宽了，80列太浪费空间。但别超过120，否则横向滚动很痛苦。
• 指针对齐：我选Left，也就是 int* p 而不是 int *p。这纯粹是个人习惯，但团队必须统一。

Clang-Tidy 配置

Clang-Tidy是静态分析工具，能帮你发现代码里的潜在问题。如果说Clang-Format管的是「颜值」，那Clang-Tidy管的就是「健康」。

我常用的检查项包括：

• 性能相关：不必要的拷贝、大对象传值、循环内分配内存等。
• 可读性相关：未使用的变量、过于复杂的表达式、命名不规范等。
• 现代C++相关：建议用 auto、nullptr、override 等。
• 安全性相关：潜在的整数溢出、未初始化变量、危险的类型转换等。

配置示例：

Checks: '
  -*,
  performance-*,
  readability-*,
  modernize-*,
  bugprone-*,
  clang-analyzer-*,
  google-*
'
WarningsAsErrors: '
  bugprone-*,
  clang-analyzer-*
'

这里我把 bugprone-* 和 clang-analyzer-* 设成了错误级别。为什么？因为这些检查项通常意味着真正的bug，不应该被忽略。我曾经在一个项目里，Clang-Tidy报了一个「未初始化变量」的警告，开发人员觉得没事就跳过了。结果线上出了随机崩溃，查了两天才定位到——就是那个未初始化的变量。

知识体系结构图

下面这张图展示了代码规范与风格的核心知识体系，以及各工具之间的关系：

避坑指南与个人经验

最后，分享几个我踩过的坑：

• 不要追求完美规范：我曾经花了两周时间制定了一份50页的编码规范，结果没人看。后来我改成10页的核心规范+工具自动检查，效果反而更好。
• 工具配置要尽早：项目启动第一天就把 .clang-format 和 .clang-tidy 放进去。等代码写到10万行再想统一格式？那是不可能的。
• 审查时别纠结格式：代码审查应该关注逻辑和设计，格式问题交给工具。如果有人在审查里说「这里少了个空格」，我会直接回复「跑一下Clang-Format」。
• 注释会过时：代码改了，注释没改，这是最常见的坑。我建议注释只写「为什么」，代码本身已经说明了「是什么」和「怎么做」。