随着万圣节越来越流行，我们想跟大家讨论一下一个在软件开发中非常普遍的问题：僵尸代码。几乎所有大家接触过的代码库里都四散着很多小段的，甚至大片大片的被注释掉的代码。这就是僵尸代码。

//目前禁用这项功能。Jimmy在写这段代码时肯定是喝醉了。

//你可能以为这里发生了恐怖的代码凶手案…不，不，我只是把它们注释掉了…

为什么称它们为僵尸代码？你知道，僵尸不并不是真的死的。就像恐怕电影里告诉我们的，尽管僵尸看起来是死人，但它们仍有能力四处出没袭击我们。相同 的道理，僵尸代码也是处于不生不死之间…它们在伺机搞砸我们的工作。注释掉的代码还活着，它们就存在我们的代码库中。程序员在维护和重构代码时会和它们遭 遇，通常是滚动屏幕时和它们擦肩而过，或是在进行关键词搜索时和它们撞个满怀。但这些代码也确实是死的，因为它们在软件产品中并不执行。因此，这些僵尸就 应该被烧掉，立刻。

僵尸代码不死之躯

我认为，有两个原因导致了僵尸代码的肆虐：懒和害怕风险。懒程序员对代码有收藏癖。他们缺乏确信的勇气和清楚的认识去删除无用的代码，于是他们就把 它们隐藏在注释里，期望有朝一日它们能复活来再次祸害人。代码需要经常的、有计划的删除，因为优秀的程序员都知道：代码就是债务。越少越好。当然，被注释掉的代码仍然是代码。

烂程序员也许会争辩说，他们注释掉这些代码是为了“万一”以后有人会需要它们。事实上，这好心反而是害了大家。这实际上说的是害怕风险，缺乏对版本 控制系统作用的信任。有版本控制系统在，删除的代码永远不会真正的死掉。它们被埋到棺材里但却活着。所以，注释代码的方法没有多大实际效用。

对于程序来说，注释掉的代码跟删掉的代码一样，不起任何作用。让代码半死不活，以僵尸的形态存在，造成技术债务，最终会让你的团队受害。要果断，删掉它们。

僵尸代码降低信噪比

当写程序时，我们一定要努力使代码里有效信息的比率越高越好。这有助于人们理解程序，更快的阅读代码，防止我们因为误解而写出有问题的代码。僵尸代 码直接的对抗代码的可理解性。它拖延我们阅读和维护代码的速度，因为它使我们在屏幕上看到更少的有效代码。它们就是视觉噪音，干扰人们的正常阅读。处于某 些原因，有些程序员会接受这种妥协的做法，可是在现实中，谁会接受这种乱糟糟的画面。想象一下，如果纽约时报看起来像这个样子：

如何阅读这断断续续的文字？噪音的增加就是对可理解性的损害。对这些被注释掉的部分，尽管它们毫不相干，甚至会误导，但你却无法对它们视而不见。有 人会说，这不是最终发布的产品，这些代码存在于开发过程中，拿它们跟发布的产品做对比，这就像拿苹果比桔子。但是请记住，被写出的每行代码平均都要被阅读10次。没错，你的代码的阅读人数没有纽约时报多，但是，你拥有的是一个最重要的忠实的阅读群体。就是我们。 Knuth对此关切进行了精辟的总结：

“编程是一种一个人告诉另一个人他想让计算机做什么的艺术。” Donald Knuth

而僵尸代码让你讲话讲不清楚。一个程序员需要去阅读被注释掉的代码吗？

僵尸代码造成歧义妨碍调试

注释掉的代码会带来歧义，人们会怀疑这些代码是否该注释掉。试想一下，你是一个来维护程序的程序员，突然看到了一片注释掉的代码，而程序就在这附近 出了问题。这个程序员的任务会变得更棘手。他需要阅读和理解这些注释掉的代码，了解注释它们带来的影响。是因为测试而注释这些代码但忘了恢复吗？也许注释 这些代码的人可以提供帮助，但他是谁？调查行动开始。多余的歧义会消耗你的时间，增加你的思考负担——本来可以是一次轻松的调试过程。

僵尸代码影响关键词搜索