重读《代码整洁之道》

第一次读《代码整洁之道》是工作第二年，像看到武功秘籍， 每一条都工整地抄进笔记。今年重读，想法变了不少 —— 有些依然是真理，有些开始可疑，有些明显过时了。 写篇「祛魅」版笔记。

一、依然是真理的部分

命名是性价比最高的重构

d、temp、data、flag2 —— 这些名字让代码的可读性归零。 Bob 大叔说「命名要名副其实」，五年过去，我经手的代码里 90% 的可读性问题还是命名。

判断方法现成：给三个月后的自己看，能不能一眼懂。 不能，就是名字没起好。

函数的第一律：短小

不追求 Bob 说的「20 行」这种具体数字（他的例子有点走火入魔）， 但「一个函数只做一件事」是对的。我现在的标准： 一个函数一屏装得下，做不到就想想是不是揽了太多。

注释解释「为什么」，不复读代码

// 判断用户是否成年
if (user.age >= 18)

这种注释是噪音。真正值钱的是：

// 这里必须等 300ms：iOS Safari 的软键盘收起有延迟，
// 不等会拿到错误的视口高度（#1024）
await sleep(300)

注释是代码的「补充病历」—— 记录那些「看起来蠢但有必要」的 决策，附上背景链接。没有 background 的注释，删掉可惜， 留着碍眼。

二、开始可疑的部分

「函数应该小于 20 行」的教条

书里把函数拆到极致，我见过有人照做：一个流程拆成八个函数， 每个起个抽象名（handleStep1、processItem），跳来跳去， 比原来的 30 行大函数更难读。

我的修正：短小的目的是「一眼看完」，不是「行数达标」。 一个 25 行但线性的函数，比五个 5 行互相跳的强。 拆分看「语义是否独立」，不看行数。

「一个函数一个抽象层级」

原则是对的（别让 SQL 和业务判断混在一起），但书里的例子 过度洁癖。真实业务里，「高层策略 + 低层细节」混排是常态， 强行分层，类数量爆炸。按「需要复用的粒度」分层， 不为纯洁性分层。

对 switch 的歧视

书里见 switch 就皱眉，推崇多态替换。但现代语言里 switch 处理「枚举分发」依然是最清晰的：

switch (action.type) {
  case 'ADD': return { ...state, count: state.count + 1 }
  case 'SUB': return { ...state, count: state.count - 1 }
}

（Redux 的核心就是 switch，谁说它不优雅。） 工具是工具，看场景。

三、明显过时的部分

示例代码全是 Java

继承至上、接口满天飞、厌恶静态方法。这套 OOP 审美 在 2026 年看着很旧。函数式、组合优于继承、TS 类型优先 —— 这些新范式书里没有。读原则，别读姿势。

「测试驱动开发（TDD）是纪律」

TDD 争论了二十年，我的立场：写核心逻辑前先写测试， 好习惯；所有代码都先写测试，形式主义。 exploratory （探索式）阶段先写实现，稳定了再补测试，更符合真实节奏。

四、五年后真正留下的三条

如果只留三条进肌肉记忆：

1. 命名花时间，值。calc 和 calculateUserDiscount 之间隔着半小时的理解成本；
2. 函数短到能一眼看完，不管具体几行；
3. 注释写「为什么」，代码写「是什么」。 两者混在一起，就是双倍难读。

五、怎么读这类「经典」

经典的问题：年代久远，姿势过时，原则长青。 读法：

• 例子当「历史文物」看，理解它想解决的问题；
• 原则用自己的项目验证一遍，合适的收下， 不合适的标记「不适用」；
• 别当圣经。Bob 大叔自己都说这是「经验」不是「定律」。

小结

《代码整洁之道》值得读一遍（工作第二年）， 值得五年后重读一次（带上怀疑）。我现在的评价： 3/5 的原则依然有效，1/5 过时，1/5 见仁见智。 它最大的贡献不是规则本身，是让你「开始在意代码质量」—— 这个在意，比任何具体条款都值钱。

（本站手札区还有其他读书笔记，欢迎翻。）