我经常在我审查的代码库中发现这样的东西：
function foo(bar) {
const baz = bar(false)
// we no longer do this for some good reason
// if (baz === 'foobar') {
// return baz
// } else {
// return bar.foobar()
// }
return baz
}
这个函数应该看起来像这样：
function foo(bar) {
return bar(false)
}
你可能在想"但是肯特!如果那个'好的理由'不再是真的，而我们以后又需要用老方法来做怎么办？"我亲爱的读者，答案是 git diff:
这就是珍贵的代码。我们可以抓住这些变化，然后轰然倒塌!我们又开始工作了!
现在你可能在想。"好的，很好，但是把注释的代码留在那里有什么问题呢？这对人们来说更容易看到事情过去是怎样的，这可能对他们有帮助，而且这也是我在代码库中永远留下我的痕迹的一种方式！"
以下是你不应该提交注释过的代码的几个原因。
对我来说，这是最大的理由，也是足以完全避免这样做的理由。我不知道你是怎么想的，但是当我看到注释过的代码时，我经常会停下手中的工作来阅读它。我想 "也许这很重要"，或者我可能只是好奇。无论是哪种情况。 我的工作流程被破坏了.
我见过这样的事情：
// dozens
//
// of
//
// lines
//
// of
//
// commented
//
// code
someImportantCode()
// dozens
//
// of
//
// more
//
// lines
//
// of
//
// commented
//
// code
在扫描一个文件时，有可能跳过someImportantCode()。在正确的语法高亮下，这种情况不太可能发生，但它可能发生，而且注释根本不值得保留。
我一直认为，唯一能告诉你代码真相的东西就是代码。当你添加注释的时候，它就已经过时了。文档注释的好处足以证明其存在的合理性（尽管你应该尽量使你的代码为除你自己之外的人提供自我文档化）。
然而，注释过的代码并不能证明其存在的合理性。不久之后，这些被注释的代码就会脱离上下文，不再被测试、加注或运行，它所使用的API已经改变或被删除，而现在它只是碍事。
同样，主要的问题是注释的代码增加了混乱，没有真正的好处。只要依靠你的版本控制系统来跟踪曾经的代码就可以了。让它去吧。
如果你是一个使用eslint的人，你可能对Gleb Bahmutov的eslint-rules感兴趣（特别是他的no-commented-out-code规则）。如果你不是eslint的人，可以听听Jamund Ferguson对JavaScript Jabber的看法。他对它的热情会说服你，你应该尝试一下 :-)
_k-why-mahm _ - 你可能会问我的问题。
问这个规则有例外吗？**答：**有。但它们很罕见。
问我正在做的东西还没有工作，怎么办？我不想等到它全部完成，因为我的电脑可能会被偷或者着火！"。**答：**把这个放在一个分支里。把完全坏掉的东西放在一个分支里是没有问题的。我个人建议，在你把这些提交放到主干上之前，先把它们压制成可以正常工作的提交，但只要放到主干上时可以正常工作，你就可以了。
问当我们完全知道代码已经完成，但在提交之前还需要一些第三方的整合，这时怎么办？我不希望失去这些知识。难道我就不能说。"//当foo完成时，取消注释这段代码"？**答：**在我看来，这个TODO应该放在一个故事里，而注释出来的代码应该放在一个开发分支里。如果第三方集成失败或被放弃怎么办？你现在必须记得删除注释和注释出来的代码。
问关于第三方集成商的例子呢？**答：**对我来说，那不是注释出来的代码，那是文档。我完全可以接受。不过，说实话，AngularJS 1项目中的文档是以文件中的注释形式出现的，这有点让我发疯。compile.js中第一行可运行的代码是第737行。但这是另一篇博文（我不是说他们这样做是错的......肯定是有取舍的）。
**问：**git历史不是很好发现......我怎样才能找到删除我想要的代码的提交？答：这是一个非常有道理的问题。删除注释过的代码不仅使它以后更难找到，而且还使未来的人不知道它以前存在过。对于寻找代码，有一些工具和git命令可以帮助你查看文件的历史。我以前也有过这样的经历，在一个文件中回溯几个月（甚至几年）其实是很微不足道的。至于知道它的存在，如果它真的那么重要，你可以加一个注释，简单解释一下那里以前存在过重要的东西，人们可以在git历史中找到它。我相信这是一个极其罕见的情况，而且我个人也想不出有什么时候需要这样做。
你有更多问题吗？请在这里留言或在twitter上与我联系。
