第四章：代码规范与风格
说实话，代码规范这事儿，刚入行的时候我也觉得烦。
不就是能跑就行吗？干嘛非得管大括号放哪、变量叫啥名？
直到有一次，我接手了一个离职同事的项目。打开代码一看——好家伙，一个函数两千行，变量名全是 a1、b2、tmp。我花了整整三天才理清楚它到底在干嘛。从那以后，我再也不敢轻视代码规范了。
核心观点：代码规范不是束缚，而是团队协作的基石。它让代码可读、可维护、可交接。
4.1 Google C++ Style Guide：行业标杆
Google C++ Style Guide 是目前业界最广泛采用的规范之一。我自己的团队也直接拿它当蓝本，只做了少量调整。
为什么选它？因为它考虑得非常全面——从命名、注释、格式，到头文件组织、类设计、异常处理，几乎覆盖了所有日常场景。
几个关键点
- 头文件：每个
.cc文件都应该有一个对应的.h文件。头文件里不要放实现，除非是内联函数或模板。 - 包含顺序：先自己的头文件，再 C 库、C++ 库、第三方库、项目内其他模块。这样能尽早发现头文件依赖问题。
- 禁止使用
using namespace std;尤其是在头文件里。我见过因为这个导致命名冲突的惨案，排查起来非常痛苦。
我的习惯：团队新成员入职，我会让他们先通读一遍 Google Style Guide，然后一起 review 几段代码。这样上手快，也容易统一认知。
4.2 命名规范：见名知意
命名是代码的「脸面」。好的命名，看一眼就知道它是干什么的。
| 类型 | 规范 | 示例 |
|---|---|---|
| 变量 | snake_case | int user_count; |
| 函数 | PascalCase | void GetUserInfo(); |
| 类 | PascalCase | class UserManager; |
| 常量 | kPascalCase | const int kMaxRetry = 3; |
| 宏 | UPPER_CASE | #define MAX_BUFFER 1024 |
嗯，这里要注意：不要用缩写。除非是业界公认的（比如 tmp、idx），否则一律写全称。我曾经见过一个 int usr_cnt，三个人猜了三种意思。
4.3 注释规范：写给人看的
注释不是越多越好。好的注释解释「为什么」，而不是「是什么」。
// 错误示范：废话注释
int i = 0; // 将 i 赋值为 0
// 正确示范：解释意图
// 使用二分查找，因为数据已排序
int index = BinarySearch(sorted_array, target);我常用的注释原则
- 公共接口必须注释：函数、类、枚举、模板参数。用 Doxygen 风格，方便生成文档。
- 复杂逻辑加注释：比如算法核心步骤、边界条件处理。
- TODO 和 FIXME 要带责任人：比如
// TODO(zhangsan): 优化性能，不然没人会去改。
避坑指南：我曾经在一个项目里看到大量「注释掉的代码」，说是「留着以后参考」。结果三年没人动过，也没人敢删。我的建议是：不要注释代码，直接删掉。版本控制系统会帮你记住历史。
4.4 代码格式化工具：clang-format
手动对齐代码？太累了，而且容易出错。
clang-format 就是干这个的。你只需要写一个 .clang-format 配置文件，然后一键格式化整个项目。
基本用法
# 格式化单个文件
clang-format -i main.cpp
# 格式化整个目录
find . -name "*.cpp" -o -name "*.h" | xargs clang-format -i常用配置项
BasedOnStyle: Google
IndentWidth: 2
ColumnLimit: 80
AllowShortFunctionsOnASingleLine: Inline
BreakBeforeBraces: Attach我个人习惯把 .clang-format 文件放在项目根目录，然后在 CI 流程里加一步格式化检查。这样所有人都能保持一致风格，谁也别想偷懒。
小技巧：在 VS Code 或 CLion 里配置保存时自动格式化。这样你写代码时完全不用操心格式，写完保存，它自动帮你整理好。
4.5 知识体系总览
下面这张图是我自己整理的代码规范知识结构，你可以把它当作一个检查清单。
4.6 总结
代码规范这件事，说白了就是「约定大于配置」。大家统一一套规则，沟通成本就降下来了。
我个人建议：先选一个成熟的规范（比如 Google 的），然后用工具（clang-format）强制执行，最后在 code review 里持续打磨。
别想着一步到位。规范是慢慢养成的习惯，不是一天建成的罗马。