为什么称它们为僵尸代码？你知道吗，僵尸其实并不是真的死的。就像恐怕电影里告诉我们的，尽管僵尸看起来是死人，但它们仍有能力四处出没袭击我们。相同的道理，僵尸代码也是处于不生不死之间…它们在伺机搞砸我们的工作。注释掉的代码还活着，它们就存在我们的代码库中。程序员在维护和重构代码时会和它们遭遇，通常是滚动屏幕时和它们擦肩而过，或是在进行关键词搜索时和它们撞个满怀。但这些代码也确实是死的，因为它们在软件产品中并不执行。因此，这些僵尸就应该被烧掉，立刻。
僵尸代码不死之躯
其实说白了，有两个原因导致了僵尸代码的肆虐：懒和害怕风险。懒程序员对代码有收藏癖。他们缺乏确信的勇气和清楚的认识去删除无用的代码，于是他们就把它们隐藏在注释里，期望有朝一日它们能复活来再次祸害人。代码需要经常的、有计划的删除，因为优秀的程序员都知道：代码就是债务。越少越好。当然，被注释掉的代码仍然是代码。
烂程序员也许会争辩说，他们注释掉这些代码是为了"万一"以后有人会需要它们。事实上，这好心反而是害了大家。这实际上说的是害怕风险，缺乏对版本控制系统作用的信任。有版本控制系统在，删除的代码永远不会真正的死掉。它们被埋到棺材里但却活着。所以，注释代码的方法没有多大实际效用。
对于程序来说，注释掉的代码跟删掉的代码一样，不起任何作用。让代码半死不活，以僵尸的形态存在，造成技术债务，最终会让你的团队受害。要果断，删掉它们。
僵尸代码降低信噪比
当写程序时，我们一定要努力使代码里有效信息的比率越高越好。这有助于人们理解程序，更快的阅读代码，防止我们因为误解而写出有问题的代码。僵尸代码直接的对抗代码的可理解性。它拖延我们阅读和维护代码的速度，因为它使我们在屏幕上看到更少的有效代码。它们就是视觉噪音，干扰人们的正常阅读。处于某些原因，有些程序员会接受这种妥协的做法，可是在现实中，谁会接受这种乱糟糟的画面？
僵尸代码造成歧义妨碍调试
注释掉的代码会带来歧义，人们会怀疑这些代码是否该注释掉。试想一下，你是一个来维护程序的程序员，突然看到了一片注释掉的代码，而程序就在这附近出了问题。这个程序员的任务会变得更棘手。他需要阅读和理解这些注释掉的代码，了解注释它们带来的影响。是因为测试而注释这些代码但忘了恢复吗？也许注释这些代码的人可以提供帮助，但他是谁？调查行动开始。多余的歧义会消耗你的时间，增加你的思考负担——本来可以是一次轻松的调试过程。
僵尸代码影响关键词搜索
在大型程序库中，grep/find命令将会是你锁定某些特定的代码片段的雷达。然而，如果程序库里到处散布着僵尸代码，很有可能你捕捉到的目标都是被注释掉的。这是干扰。浪费时间。
僵尸代码影响代码重构
反省(重构)能修复我们的灵魂。我们应该永远把代码收拾得比你想象的要整洁。然而，当一个类或方法包含有大量的僵尸代码时，事情就不好处理了。如果重构这段程序，我是否还要参考注释掉的代码？它们近期将会被重新使用吗？它会影响我的新版的实现吗？这些问题对于维护的程序员来说本该不需要回答的。
此外，集成重构工具根本不会考虑这些注释掉的代码。因此，当方法，变量，类被重命名或修饰符改变时，这些注释掉的代码就不会同步做修改。当你再想把注释掉的代码复活时，它们很可能根本不能编译。
心里的核对表
如果你打算要注释一段代码，请先问问自己：
如果有可能的话，什么时候会取消注释？
是否能删掉它，如果日后有需要，从版本控制系统里找回？
对这些未完成的、有可能会回滚的代码，能否用版本分支来处理？
这种需要来回切换注释的功能可否通过配置实现？
重构时也需要重构这些注释掉的代码吗？
让我们开启僵尸代码大清剿吧！
网站开发与优化
请备注：网站或服务器