重读《代码整洁之道》· 摘录 5 段让我重新思考的话

第一次读这本书是三年前，刚入行没多久，看完只记得"命名要规范、函数要短"这些表层建议。这周重新翻开，发现很多段落读起来完全不同了——大概是因为踩过的坑够多，才能听懂作者在说什么。

关于命名

三年前我以为这是在说"名字要起得长一点"。现在再看，作者的意思是：当你用注释解释一个变量是干什么的，你已经知道它该叫什么了。问题是你偷懒了。

关于函数

三年前我嗤之以鼻——20 行怎么可能？现在我的代码里很少有超过 30 行的函数，大部分都在 5–15 行之间。短函数真的更易读，前提是命名够好。

关于注释

这一条三年前没读懂，现在感同身受。大多数注释都是写给过去的自己的，但过去的自己其实知道代码做了什么——他只是想告诉自己"为什么这么做"。所以注释真正该写的是"为什么"，不是"做了什么"。

关于错误处理

这一段我印象最深。真实项目里 80% 的代码是错误处理，不是夸张。我后来养成了一个习惯：写完业务逻辑后，看一眼错误处理占总代码量的比例，超过 50% 就该停下来重构。

关于边界

三年前我嫌这样啰嗦——直接调用不是更快？现在看，所有"未来不会换"的依赖最后都换了，所有"我们肯定不会用"的库最后都换了。适配层不是过度设计，是给未来的自己留条退路。

一点感慨

同一本书在不同阶段读出来是不一样的。三年前读这本书，它告诉我什么是好代码；现在读，它告诉我为什么要这样写好代码。

也许再过三年再读一次，又会读出不一样的东西。这就是好书的魅力。