翻开《代码整洁之道》第一章，代码读书Bob大叔就扔出一句话：让代码比你来时更干净。整洁之道这话听着像鸡汤，笔记但仔细琢磨，代码读书它其实是整洁之道在说一件很具体的事——你每次提交代码，都应该让营地比之前更整洁一点。笔记不是代码读书推倒重来，不是整洁之道大扫除，就是笔记顺手把那个变量名改清楚，把那段重复逻辑抽出来。代码读书

我见过太多项目死在“先跑通再说”这五个字上。整洁之道去年接手一个后台系统，笔记一个函数三百多行，代码读书变量叫 a1、整洁之道temp2、笔记flag。注释写着“暂时这样”。那个“暂时”是四年前写的。每次改需求，我得先花半小时理清这三百行到底在干嘛，然后小心翼翼地塞进第五个 if-else。这不是技术债，这是技术高利贷。

Bob大叔对命名的执念近乎偏执。他说变量名应该回答“为什么存在、做什么用、怎么用”。int d; 这种写法该被钉在耻辱柱上。我以前觉得这是小题大做，直到有次调试，满屏的 data、list、map 让我完全分不清哪个是用户数据哪个是订单数据。后来改成 userList、orderMap，虽然敲键盘多花两秒，但读代码时脑子少转三个弯。这笔账怎么算都划算。

函数要短。多短？Bob说最好二十行以内。我试过。把一段八十行的校验逻辑拆成六个小函数后，主流程变成了一串自解释的调用：validateUserInput()、checkPermission()、normalizeData()……每个小函数只做一件事，测试也好写。以前改一个校验规则，我得在八十行里找那行 if，现在直接定位到对应函数，改完跑测试，两分钟搞定。

注释这件事上，Bob的态度很明确：能靠代码说清楚的就别写注释。糟糕的代码才需要注释来补。我见过最离谱的注释是 // 设置flag为true，下面一行 flag = true;。这种注释不如删掉，省得以后代码改了注释没改，反而误导人。真正有价值的注释是解释“为什么这么做”，比如 // 这里必须用double，float精度不够导致金额计算误差。这种信息代码本身表达不了。

错误处理那块，Bob建议用异常代替返回错误码。我深有体会。以前写C的时候，每个函数调用后都要 if (ret != OK)，一层层往上传递错误码，主逻辑被淹没在错误检查里。换成异常后，正常流程一条线走到底，异常统一在顶层捕获。代码干净了不止一个档次。

书里提到“童子军军规”那节，我印象最深。它不是说你要专门花时间重构，而是每次改代码时顺手做点小改进。改个名字，拆个函数，删段死代码。这些动作单独看微不足道，但积累起来，代码库会慢慢变好。反过来，每次都在烂代码上糊新功能，那代码库只会加速腐烂。

读完这本书最大的收获，不是学会了什么具体技巧，而是养成了一种习惯：写完代码后多看两眼。这两眼往往能发现一个可以改好的名字，一段可以抽出来的逻辑，一个可以删掉的注释。就这两眼，让代码从“能跑”变成“能读”。

代码是写给人看的，顺便让机器执行。这个顺序搞反了，项目就离推倒重来不远了。