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

说实话，我刚入行那会儿，觉得代码规范就是个形式主义。

能跑就行，管它长啥样呢？

直到有一次，我接手了一个遗留项目。那个项目有十几万行代码，变量名全是 a1、b2、temp 这种。函数名有的用下划线，有的用驼峰，有的干脆就是拼音缩写。我花了整整两周才搞清楚一个模块的逻辑。

嗯，从那以后，我再也不敢轻视代码规范了。

3.1 为什么需要代码规范？

代码首先是给人看的，其次才是给机器执行的。

你想想看，一个团队里五个人，每个人写代码的风格都不一样。A 喜欢用 Tab 缩进，B 喜欢用 4 个空格，C 喜欢把大括号放在行尾，D 喜欢另起一行。合并代码的时候，光格式化就能吵半天。

我个人习惯是：统一规范，减少内耗。

3.2 Google C++ Style Guide 核心要点

Google 的 C++ 风格指南，可以说是业界最流行的规范之一。我建议每个 C++ 开发者都至少读一遍。

这里我挑几个最常用的点说说。

3.2.1 命名规范

命名这件事，看似简单，其实坑很多。

类型	命名风格	示例	说明
变量	snake_case	int user_count;	普通变量、函数参数都用这个
类成员变量	snake_case + 尾下划线	int user_count_;	一眼就能看出是成员变量
函数	PascalCase	void GetUserInfo();	首字母大写，每个单词首字母大写
类/结构体	PascalCase	class UserManager;	和函数一样，但上下文能区分
宏	UPPER_SNAKE_CASE	#define MAX_BUFFER_SIZE 1024	全大写，下划线分隔
枚举值	UPPER_SNAKE_CASE	enum Color { RED, GREEN, BLUE };	和宏一样，但建议用 enum class

3.2.2 代码格式化规则

Google 风格里还有一些具体的格式化要求：

• 缩进：2 个空格，不要用 Tab
• 行宽：最多 80 个字符
• 大括号：函数和类的大括号另起一行，控制语句的大括号放在行尾
• 指针和引用：* 和 & 紧贴变量名，而不是类型名

举个例子：

// 好的写法
int* ptr = &value;
if (condition) {
  DoSomething();
}

// 不好的写法
int *ptr = &value;
if (condition)
{
  DoSomething();
}

为什么会这样？

我个人理解是：int* ptr 这种写法，把 * 和类型绑在一起，更符合「指针类型」的语义。但 Google 风格偏偏要求 int* ptr 写成 int* ptr 其实也可以，只是他们选择了另一种约定。

嗯，这里要注意：风格没有绝对的对错，关键是团队统一。

3.3 代码格式化工具：clang-format

手动格式化代码？太累了。

我建议你直接用 clang-format。这个工具可以自动把你的代码格式化成指定的风格。

3.3.1 安装 clang-format

在 Ubuntu 上：

sudo apt install clang-format

在 macOS 上：

brew install clang-format

在 Windows 上，你可以通过 LLVM 的安装包获取。

3.3.2 配置文件：.clang-format

在项目根目录创建一个 .clang-format 文件：

BasedOnStyle: Google
IndentWidth: 2
ColumnLimit: 80
PointerAlignment: Left
AccessModifierOffset: -2

这个配置的意思是：基于 Google 风格，缩进 2 个空格，行宽 80 字符，指针靠左对齐。

3.3.3 使用 clang-format

格式化单个文件：

clang-format -i main.cpp

格式化整个目录：

find . -name "*.cpp" -o -name "*.h" | xargs clang-format -i

如果你用 VS Code，可以安装 C/C++ 扩展，然后在设置里开启「保存时自动格式化」：

"editor.formatOnSave": true,
"C_Cpp.clang_format_fallbackStyle": "Google"

这样每次保存代码，它都会自动帮你格式化。

3.4 本章知识体系

下面这张图，是我整理的本章节核心逻辑：

3.5 避坑指南

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

• 不要手动格式化别人的代码。 我曾经因为看不惯同事的代码风格，顺手帮他格式化了一下，结果 Git 历史里全是格式变更，真正的逻辑改动反而被淹没了。后来我们约定：只格式化自己改动的部分。
• 宏命名一定要小心。 宏没有作用域，很容易和别的宏冲突。我建议能用 constexpr 或 enum 的地方，就别用宏。
• clang-format 不是万能的。 它只能格式化代码，不能帮你检查命名是否合理。规范最终还是要靠人来执行。

好了，这一章就到这里。记住：规范的代码，是对未来自己的善意。