14.1 例子：不好的名称会导致bug

有时，即使是一个命名不当的变量也会产生严重的后果。我曾经修复过的最具挑战性的bug就是因为一个糟糕的名称选择。在20世纪80年代末和90年代初，我和我的研究生们创建了一个叫做Sprite的分布式操作系统。在某些时候，我们注意到文件偶尔会丢失数据：其中一个数据块突然全都变成了零，即使该文件没有被用户修改。这个问题并不经常发生，所以追踪起来特别困难。有几个研究生试图找到这个错误，但他们无法取得进展，最终放弃了。然而，我认为任何未解决的bug都是一种不可容忍的个人侮辱，所以我决定追踪它。

这花了我六个月的时间，但我最终发现并修复了这个bug。这个问题实际上很简单（就像大多数错误一样，一旦你发现了它们）。文件系统代码将变量名称block用于两个不同的目的。在某些情况下，block指的是磁盘上的一个物理块号；在其他情况下，block指的是文件中的一个逻辑块号。不幸的是，在代码中的某一点上，有一个包含逻辑块号的block变量，但它被意外地用在了需要物理块号的环境中；结果，磁盘上一个不相关的块被覆盖成了0。

在追踪这个bug的时候，有几个人，包包括我自己在内的几个人都阅读了错误代码，但我们从未注意到问题所在。当我们看到变量block被用作物理块号时，我们条件反射地认为它确实是一个物理块号。检测过程花了很长时间，最终表明损坏一定发生在特定的某条语句中，然后我才能够克服由名称造成的心理障碍，检查出它的值到底来自哪里。如果不同类型的块使用了不同的变量名，比如fileBlock和diskBlock，就不太可能发生错误；程序员会知道fileBlock不能在这种情况下使用。

不幸的是，大多数开发者并没有花很多时间考虑名字的问题。他们往往会使用想到的第一个名称，只要它与它所命名的东西相当接近就可以了。例如，block是一个与磁盘上的物理块和文件中的逻辑块都非常接近的名称；它当然不是一个糟糕的名称。即便如此，它还是导致追踪一个微妙的bug而花费了大量的时间。因此，你不应该满足于那些只是“相当接近”的名称。花一点额外的时间来选择优秀的名称，这些名称要精确、明确和直观。额外的关注将很快得到回报，而且随着时间的推移，你将学会快速选择好的名称。