代码规范与代码审查：Google C++ Style、Clang-Tidy静态分析、代码审查清单、自动化格式化
说实话，代码规范这事儿，我年轻时觉得是束缚。那时候写代码追求的是「快」——功能跑通就行，管它什么缩进、命名、注释。直到有一次，我接手了一个离职同事的项目，打开代码一看……嗯，那感觉就像走进了一个没人打扫的仓库。变量名全是 a1、tmp、xxx，函数动不动就上千行，缩进风格每两百行换一种。我花了整整两周才理清楚那套逻辑。
从那以后，我彻底明白了：代码首先是写给人看的，其次才是给机器执行的。今天我们就来聊聊，怎么用一套系统的方法，把代码规范这件事落地。
一、Google C++ Style：为什么选它？
市面上C++编码规范很多，有LLVM的、有Qt的、有各家大厂内部的。我个人习惯用 Google C++ Style 作为基准。为什么？
- 覆盖面广：从命名、注释到头文件组织、智能指针使用，都有明确规则。
- 社区认可度高：很多开源项目（如TensorFlow、gRPC）都在用。
- 有配套工具：cpplint可以直接检查，省心。
但注意，Google Style不是金科玉律。我在项目中遇到过团队非要全盘照搬，结果跟现有代码风格冲突严重，改得鸡飞狗跳。我的建议是：以Google Style为蓝本，根据项目实际情况做裁剪。比如Google禁止异常，但你的项目用了异常，那就别硬套。
核心原则：团队统一比「哪个风格更好」重要一百倍。
二、Clang-Tidy静态分析：让工具替你盯
人眼审查代码，总有疲劳的时候。这时候就需要静态分析工具上场了。Clang-Tidy是我最常用的C++静态分析工具，没有之一。
它能检查什么？我列几个常用的检查项：
| 检查类别 | 典型检查项 | 说明 |
|---|---|---|
| 命名规范 | readability-identifier-naming | 检查变量、函数、类名是否符合规范 |
| 代码风格 | google-readability-* | Google Style相关检查 |
| 潜在Bug | bugprone-* | 检测空指针、未初始化变量等 |
| 性能 | performance-* | 不必要的拷贝、低效容器使用 |
| 现代C++ | modernize-* | 建议使用C++11/14/17新特性 |
举个例子，你写了个函数参数是 std::string，但没加 const &。Clang-Tidy会直接报：performance-unnecessary-value-param。说白了就是提醒你：别没事拷贝字符串，浪费内存。
我曾经在一个项目中，用Clang-Tidy一次性扫出了300多个潜在问题。其中有一半是未初始化的成员变量——这些在运行时可能表现为随机崩溃，特别难排查。工具一跑，问题全暴露了。
小技巧：在CMake中集成Clang-Tidy，每次编译自动检查：set(CMAKE_CXX_CLANG_TIDY "clang-tidy;--checks=*")
三、代码审查清单：别凭感觉审查
很多人做Code Review，就是打开PR，扫一眼，看到几个明显的命名问题就过了。这其实不够。我建议团队准备一份 代码审查清单，每次Review时逐项核对。
下面是我自己整理的一份清单，供你参考：
- 功能正确性：代码逻辑是否覆盖了所有边界情况？有没有遗漏的异常路径？
- 可读性：变量名、函数名是否自解释？注释是否必要且准确？
- 性能：有没有不必要的拷贝？有没有可以优化的循环？
- 安全性：有没有潜在的缓冲区溢出？有没有未检查的输入？
- 可维护性：代码是否过度耦合？有没有重复代码？
- 测试覆盖：新增代码是否有对应的单元测试？
你想想看，如果每次Review都按这个清单走一遍，质量能差到哪去？
注意：审查清单不是用来「找茬」的，而是用来「对齐标准」的。我曾经见过有人把Review变成个人攻击，那味道就变了。记住，我们是在一起把代码变好，不是在比谁更厉害。
四、自动化格式化：解放双手
代码格式问题，比如缩进用空格还是Tab、大括号换不换行……这些争论毫无意义。直接用工具统一格式化就好。
我推荐 clang-format，配合Google Style的配置文件：
# .clang-format
BasedOnStyle: Google
IndentWidth: 2
ColumnLimit: 100
AllowShortFunctionsOnASingleLine: None
然后在项目中配置git hooks，每次提交前自动格式化。这样所有人的代码风格就完全一致了，Review时再也不用为「这里多了个空格」这种破事浪费时间。
我记得有一次，团队里有人死活不习惯Google Style的缩进，觉得2个空格太少了。我说行，那咱们统一用4个空格，但所有人都得改。最后大家投票，还是选了Google默认的2空格——因为改配置太麻烦了（笑）。
五、知识体系总览
下面这张图，把代码规范与审查的核心流程串起来了：
六、落地建议
说了这么多，怎么真正落地？我分享几个实操经验：
- 别一上来就全盘推行：先选一个模块试点，跑通流程，再推广到整个项目。
- 工具先行，人工为辅：能用工具自动检查的，就别让人工去盯。Clang-Tidy和clang-format能解决80%的规范问题。
- 审查要有时效性：PR提交后24小时内完成Review，拖太久大家都没热情了。
- 建立正向反馈：谁写的代码规范、审查认真，公开表扬。别只盯着问题不放。
我的个人习惯：每次提交代码前，先跑一遍 clang-format 和 clang-tidy，确保本地没问题再push。这样Reviewer看到的基本就是干净代码，双方都省心。
好了，关于代码规范与审查，今天就聊到这儿。这些东西看起来琐碎，但长期坚持下来，你会发现团队的整体效率提升一大截。毕竟，好代码不是写出来的，是改出来的。