什么样的代码读起来舒服

聊代码的美，很容易聊成个人偏好。有人喜欢短，有人觉得展开写更清楚，连括号放在哪里都能争一阵。

这些我也有偏好，不过真正接手一段代码时，最在意的通常是另一件事：能不能比较快地弄明白它在做什么。尤其是过了几个月，再打开自己写的代码，如果还得猜当时的意图，就知道有些地方没有写清楚。

函数名、变量名、代码放在哪个文件，看起来都是小事。但名字含糊一点，调用再绕一点，读的人就得把这些线索一直记在脑子里。真正要修改的地方可能只有两行，找到它却要花很久。

少写几行之前，先看有没有改意思

比如判断用户是否已满十八岁，可以写得很啰嗦：

const isAdult = user != null && user.age != null
  ? user.age >= 18
  : false;

如果约定年龄只能是数字或空值，可以直接写：

const isAdult = (user?.age ?? -1) >= 18;

这里用负数表示年龄缺失，不把空值误当成一个有效年龄。在这个输入约定下，两种写法得到的结果相同，后者也少了一次阅读上的转弯。

但这种改法并不是越短越好。如果年龄来自外部输入，数字、字符串和异常值混在一起，就应该先校验，而不是指望一行比较把问题都处理掉。还有些表达式，压缩以后只有作者看得懂，那我宁可把它展开。

判断写得好不好，最终还是得看读它的人要费多少劲，而不是看删掉了几个字符。

约定有时比个人风格重要

一个项目里，如果相似的事情总有不同写法，维护起来会很累。这个模块这样命名，另一个换一套；这里返回空值，那里抛异常，却又没有明显的理由。

每一种选择单拿出来都可能说得通，放在一起却增加了猜测。改代码的人得先确认这里遵循的是哪套习惯，再去理解业务。

所以进到已有项目，我更愿意先沿用周围的写法。真有值得改的地方，再把原因和影响讲明白，不为留下自己的风格多造一套规则。

第一版代码也很少就让人满意。先把逻辑和边界做对，写出必要的检查，再回头看哪里重复、哪里别扭。有时改一个名字就顺了，有时需要把几件搅在一起的事拆开。并不是每次都要重构成一种新架构。

我越来越喜欢那种没什么炫耀意味的代码。看完知道它为什么这样写，出了问题知道去哪里找，下一次改动也不用特别小心翼翼。能做到这些，我就觉得它挺好看。