代码规模控制：减少代码膨胀，函数拆分与内联的平衡，死代码消除

聊到代码规模控制，我脑子里第一个蹦出来的画面，是几年前接手的一个通信协议栈项目。那代码，怎么说呢，一个函数能写上千行，编译出来的固件直接撑爆了芯片的Flash。我当时就一个感觉：这哪是写代码，这是在堆代码。

代码膨胀，说白了就是你的程序里塞了太多没用的东西。它会让你的可执行文件变大，缓存命中率下降，甚至拖慢运行速度。嵌入式系统里，Flash和RAM都是寸土寸金，代码膨胀就是犯罪。

函数拆分：别让一个函数干所有事

我见过最夸张的，是一个函数里同时做了协议解析、状态机跳转、数据校验、日志打印。你想想看，这种函数谁敢动？动一处，可能崩一片。

函数拆分的核心原则，我总结为三点：

• 单一职责：一个函数只做一件事。比如解析协议就只解析协议，别在里面打印日志。
• 控制长度：我个人习惯，一个函数尽量不超过50行。超过这个数，我就开始琢磨是不是该拆了。
• 接口清晰：拆出来的函数，参数别太多。超过3个参数，我就考虑用结构体传参。

举个例子，假设你有一段代码，既要计算CRC，又要做数据拷贝：

// 不好的写法：一个函数干两件事
void process_data(uint8_t *src, uint8_t *dst, uint32_t len) {
    uint32_t crc = 0;
    for (uint32_t i = 0; i < len; i++) {
        crc += src[i];  // 简单CRC
        dst[i] = src[i]; // 数据拷贝
    }
    // 其他处理...
}

拆成两个函数后，每个函数职责单一，也方便复用：

// 拆分成两个函数
uint32_t calc_crc(uint8_t *data, uint32_t len) {
    uint32_t crc = 0;
    for (uint32_t i = 0; i < len; i++) {
        crc += data[i];
    }
    return crc;
}

void copy_data(uint8_t *src, uint8_t *dst, uint32_t len) {
    for (uint32_t i = 0; i < len; i++) {
        dst[i] = src[i];
    }
}

函数内联：用空间换时间

函数内联，说白了就是把函数调用直接替换成函数体。好处是省去了调用开销，坏处是代码体积会变大。

什么时候该用内联？我一般看这几点：

• 函数体很小：比如只有两三行，调用开销占比大，内联划算。
• 调用频率极高：比如在热循环里被调了上万次，内联能明显提速。
• 函数是纯计算：没有复杂的控制流，内联后编译器容易优化。

举个例子，一个简单的取最小值函数：

// 适合内联的小函数
static inline int min(int a, int b) {
    return (a < b) ? a : b;
}

但要注意，inline只是建议，编译器不一定听你的。我遇到过几次，加了inline，编译器愣是没内联，后来查了手册才知道，函数体太大或者有递归，编译器直接无视了。

死代码消除：别留垃圾

死代码，就是那些永远不会被执行到的代码。比如：

• 永远不会进入的if分支
• 定义了但从未使用的变量
• 被注释掉的代码块
• 调试阶段留下的日志打印

这些代码不仅占空间，还会让阅读者困惑。我见过一个项目，里面有一大段被#if 0包起来的代码，注释写着「这段可能以后有用」。结果三年过去了，那段代码从来没被启用过。

消除死代码，我一般用这几个方法：

1. 编译器优化：开启-O2或-Os，编译器会自动干掉一些明显的死代码。
2. 静态分析工具：比如PC-Lint、Coverity，能帮你找出未使用的函数和变量。
3. 代码审查：每次提交代码时，顺手检查有没有遗留的调试代码。
4. 条件编译清理：项目稳定后，把那些#ifdef DEBUG之类的调试代码统一清理掉。

举个例子，下面这段代码里，unused_var和dead_function就是典型的死代码：

void process(int flag) {
    int unused_var = 0;  // 从未使用
    if (flag) {
        // 正常处理
    } else {
        // 永远不会进入的分支
        dead_function();
    }
}

void dead_function() {
    // 这个函数永远不会被调用
    printf("This is dead code\n");
}

知识体系总览

下面这张图，是我自己梳理的代码规模控制的核心逻辑。你看一眼，基本就能把握住本章的脉络：

实际项目中的平衡策略

我在实际项目中，一般会按这个优先级来决策：

场景	优先策略	原因
Flash空间紧张	死代码消除 + 减少内联	先腾出空间，再考虑性能
性能瓶颈在热循环	关键函数内联	用空间换时间，只优化热点
代码可维护性差	函数拆分	先让代码能看懂，再谈优化
既有体积限制又有性能要求	拆分 + 选择性内联	拆出热点函数，只内联那些真正关键的

嗯，代码规模控制这件事，说到底就是「取舍」二字。你不可能既要代码体积最小，又要执行速度最快，还要代码可读性最好。找到你的项目最看重的那个点，然后围绕它做平衡。我在项目中吃过不少亏，也积累了一些经验，希望这些能帮你少走弯路。

---

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