代码规范与重构:Google C++ Style、命名规范、代码审查、重构技巧

说实话,我见过太多项目死在代码混乱上。不是技术不行,是代码烂到没人敢改。今天聊的这些东西,说白了就是让你写的代码能活得更久。

一、Google C++ Style 到底在讲什么?

Google C++ Style Guide 我看了不下十遍。每次带新团队,第一件事就是让大家先读这个。为什么?因为它解决了一个核心问题:团队协作中的认知负担

我个人习惯,不管项目大小,先定好代码风格。Google 这套东西,经过全球成千上万工程师的检验,踩过的坑比我们写过的代码都多。

核心原则:代码是写给人看的,顺便给机器执行。

举个例子,Google 要求头文件自包含。什么意思?就是每个 .h 文件自己就能编译通过,不依赖外部顺序。我在项目中遇到过,有人把 #include 写在 .cpp 里,结果另一个文件引用这个头文件时,编译报错找半天。嗯,这种问题排查起来特别恶心。

二、命名规范:名字起得好,bug 少一半

你想想看,一个变量叫 a 和叫 userCount,哪个更容易理解?

Google 的命名规则其实很简单:

类型 命名风格 示例
变量 snake_case int user_count;
函数 PascalCase void GetUserInfo();
PascalCase class UserManager;
常量 kPascalCase const int kMaxRetry = 3;
ALL_CAPS #define MAX_BUFFER 1024

我曾经接手过一个项目,变量名全是 a1b2tmp 这种。改一个 bug 要花三天,因为根本不知道这些变量是干嘛的。后来我花了一周重构命名,代码量没变,但维护效率提升了至少三倍。

小技巧:命名时问自己一个问题——如果别人没看注释,光看名字能猜出这个变量/函数是干嘛的吗?

三、代码审查:不是找茬,是互相学习

很多人觉得 code review 就是挑毛病。其实不是。我理解的代码审查,是让代码质量在提交前再过一个脑子。

审查时我主要看这几点:

  • 逻辑正确性——代码能不能跑对?边界情况处理了吗?
  • 可读性——换个人来看,能不能快速理解?
  • 性能隐患——有没有不必要的拷贝?有没有潜在的内存泄漏?
  • 风格一致性——跟项目现有风格是否统一?

我记得有一次审查,同事写了个循环,里面每次都要 new 一个对象。我说你这样搞,性能会崩。他还不信,结果压测一跑,QPS 直接掉了一半。从那以后,他每次提交前都会自己先跑一遍性能测试。

避坑指南:我曾经见过有人把 code review 当成走过场,直接点 approve。结果线上出了严重 bug,追查下来是代码逻辑写反了。所以,认真看每一行代码,别偷懒。

四、重构技巧:小步快跑,别想一口吃成胖子

重构最怕什么?怕改完跑不起来。我建议的策略是:每次只改一个点,改完就测试

常用的重构手法:

  1. 提取函数——一段代码超过 20 行,就考虑拆成小函数
  2. 消除重复——同样的逻辑出现两次以上,就该封装
  3. 简化条件——嵌套超过三层,说明设计有问题
  4. 替换魔法数字——所有硬编码的数字,都改成常量

举个实际例子:

// 重构前
if (status == 1) {
  // 处理成功
} else if (status == 2) {
  // 处理失败
} else if (status == 3) {
  // 处理超时
}

// 重构后
enum class Status { kSuccess = 1, kFailure = 2, kTimeout = 3 };

switch (status) {
  case Status::kSuccess: HandleSuccess(); break;
  case Status::kFailure: HandleFailure(); break;
  case Status::kTimeout: HandleTimeout(); break;
}

你看,重构后的代码,意图一目了然。而且以后加新状态,直接加枚举和对应处理函数就行,不会影响现有逻辑。

个人经验:重构前一定要有单元测试覆盖。没有测试的重构,就像蒙眼走钢丝。我吃过这个亏,改完一个函数,结果把另一个模块搞崩了,查了两天才发现。

五、知识体系总览

下面这张图,是我对代码规范与重构的整体理解。你可以把它当成一个检查清单,每次写代码时对照一下。

代码规范与重构 Google C++ Style 头文件自包含 禁止 using namespace 智能指针优先 命名规范 变量: snake_case 函数: PascalCase 常量: kPascalCase 代码审查 逻辑正确性 可读性 性能隐患 重构技巧 提取函数 消除重复 简化条件

这四个方面,其实是一个整体。风格规范是基础,命名规范是门面,代码审查是保障,重构技巧是进阶。缺一个,代码质量都会打折扣。

最后说一句:好的代码不是写出来的,是改出来的。别怕重构,怕的是不改。


公众号:蓝海资料掘金营,微信deep3321