评论被删除的代码
评论被删除的代码是否是一个好习惯？ 例如：
// Code to do {task} was removed by Ajahn on 10/10/08 because {reason}. 我的开发人员在同行评审中发现有人注意到我们应该对要删除的代码行进行评论。 我认为这是一个可怕的build议，因为它用无用的评论混淆了代码。 我们哪一个是对的？
一般来说，被移除的代码不应该被注释掉，正是因为它混淆了代码库（以及为什么要评论一些不存在的东西？）。
您的缺陷跟踪系统或源代码pipe理工具是这些评论所属的地方。
在注释代码（而不是删除）时有一些（罕见的）情况是一个好主意。 这是一个。
我有一行似乎是好的和必要的代码。 后来我意识到这是没有必要的，也是有害的。 我没有删除这一行，而是加了一个注释：“下面这行是错误的，因为这样和那样的原因”。 为什么？
因为我确信下一个代码的读者会首先认为没有这行是一个错误，并会尝试将其添加回来。 （即使读者是我两年后）我不指望他先咨询源代码pipe理。 我需要添加评论来警告他这种棘手的情况。 并有错误的线路，错误的原因是最好的办法。
我同意在代码中删除代码并不是一个好主意。
应该通过一个版本控制系统来查看代码历史logging，这个系统可以find旧代码，以及它被删除的原因。
你应该总是删除代码。
至于能够看到旧的/删除的代码，这是版本控制。
取决于拆除的原因。
如果代码在那里但被删除的信息对于维护代码的人可能是有帮助的（也许作为“不要这样做”的标志），那么我应该把这些意见看作是人们维护代码的暗示在那里。
否则，在每个代码更改中添加名称和date的详细注释只是使整个事情变得不可读。
我认为这是相当无用的，并使代码不易读。 试想一下，有些事情会是什么样的。
// removed because of this and that /* removed this stuff because my left leg... */ doSomething(); // this piece of has been removed, we don't need it...
你会花半个小时来找出发生了什么事
问题是，为什么要删除代码？
这是无用的吗？ 把它放在首位是不是一个错误？
我的观点不需要任何评论。
debugging时很有用，但没有理由以这种方式签入代码。 源代码控制的全部重点是能够恢复旧版本，而不会使代码与注释代码混淆。
我会build议，是的，这是一个很好的做法，以评论已被删除的代码，但不是在代码本身 。
为了进一步澄清这个问题，你应该使用一个源代码控制系统（SCCS），它允许某种forms的签入注释。 那就是你应该把关于为什么代码被删除的意见的地方。 SCCS将提供关于代码发生了什么的完整背景历史logging，包括已被删除的内容。 通过添加签入评论你进一步澄清了历史。
在代码中直接添加注释只会导致混乱。
最近的共识（来自这里的其他讨论）是代码应该被删除。
我个人会将代码注释掉，并用date或原因对其进行标记。 如果它是旧的/陈旧的，我正在通过该文件，然后我把它删除。 版本控制使回归变得容易，但不像取消注释那样容易
这听起来像你正试图解决你的代码版本。 从理论上讲，这听起来像是个好主意，但实际上很快就会变得非常混乱。
我强烈build议将代码注释掉以便进行debugging或运行其他testing，但在最终决定完成后将其从文件中彻底删除！
得到一个好的版本pipe理系统，我想你会发现评论变化的做法是混乱的。
这里没有人写了很多关于为什么你不应该留下注释掉的代码，除了看起来很乱。 我认为最大的原因是代码可能会停止工作。 没有人在编译它。 没有人通过unit testing来运行它。 当人们重构其余的代码时，他们不会重构它。 所以很快，这将变得毫无用处。 或者比毫无用处 – 有人可能会取消注释，盲目地相信它是有效的。
如果我们仍然在做一个项目的重大devise/开发，有时候我会注释掉代码。 在这个阶段，我通常尝试几种不同的devise，寻找正确的方法。 有时候正确的做法是我早些时候已经尝试过的。 所以如果这个代码在源代码控制的深处没有丢失，那就好了。 但是，一旦devise已经解决，我会摆脱旧的代码。
总的来说，我倾向于非常稀疏地发表评论。 我相信好的代码应该很容易阅读，没有太多的评论。
我也版本我的代码。 我想我可以在最近的二十个签证上做一些比较，看看是否有特定的原因发生了变化。 但是，对于大多数变化来说，这将是一个巨大的浪费。
所以我试着巧妙地评论我的代码。 如果某个代码因为一个相当明显的原因而被删除，我不会麻烦评论删除。 但是，如果一段代码因为一个微妙的原因被删除（例如，它执行了一个函数，现在正在由另一个线程来处理），我将注释掉或删除代码并添加一个横幅注释原因：
// this is now handled by the heartbeat thread // m_data.resort(m_ascending);
要么：
// don't re-sort here, as it is now handled by the heartbeat thread
就在上个月，我遇到了一年前更改过的一段代码，以解决某个特定问题，但没有添加注释来解释原因。 这是原始代码：
cutoff = m_previous_cutofftime;
这里是代码，因为它是最初固定的，以恢复中断状态时使用正确的截止时间：
cutoff = (!ok_during) ? m_previous_cutofftime : 0;
当然，另一个无关的问题出现了，碰巧碰到相同的代码行，在这种情况下，将其恢复到原来的状态。 所以这个新问题现在已经解决了，但是老问题突然变得重新开始了。 D'哦！
所以现在签入的代码看起来像这样：
// this works for overlong events but not resuming // cutoff = m_previous_cutofftime; // this works for resuming but not overlong events // cutoff = (!ok_during) ? m_previous_cutofftime : 0; // this works for both cutoff = (!resuming || !ok_during) ? m_previous_cutofftime : 0;
当然，YMMV。
作为唯一的反对声音，我会说在特殊情况下有一个注释代码的地方。 有时候，你会得到一些旧数据，这些旧数据是通过旧代码运行的，而最清晰的做法是将旧代码放在源代码中。 在这种情况下，我可能会留下小小的注释，说明为什么旧代码只是被注释掉了。 任何随之而来的程序员都能够理解仍然存在的数据，而不必在心理上检测到需要检查旧版本。
通常情况下，我发现代码完全可恶，我经常删除它。
如果你正在删除代码。 你不应该评论你删除它。 这是源代码pipe理的全部目的（您正在使用源代码pipe理？正确？），并且在您声明注释时会混淆代码。
我同意这是一个可怕的build议。 这就是为什么你有源代码pipe理有修改。 如果你需要回头看看两个版本之间有什么变化，请对两个版本进行比较。
我讨厌看到代码杂乱无章的代码。 删除代码，并写一个提交消息，说明为什么被删除。 你确实使用源代码控制，不是吗？
不要用死码来代替活动代码。
我将把我的声音添加到共识中：将代码放在源控制存储库中的代码删除的原因，而不是在代码中。
这是那些“破碎的”窗户，像编译器提示/警告没有解决的问题之一。 有一天它会伤害你，而且会增加团队的</s> </s>。
在版本控制中的评论检查可以跟踪什么/为什么代码被删除 – 如果开发人员没有留下一个笔记，跟踪他们，并扼杀他们。
一个小故事，为了好玩：几年前，我在一家公司，对源代码版本控制一无所知（后来他们得到了这样的工具…）。
所以他们有一个规则，在我们的C源代码中：“当你做出改变时，用预处理macros禁用旧代码”：
#ifdef OLD /* PL - 11/10/1989 */ void Buggy() { // ... } #else void Good() { // ... } #end
不用说，我们的消息很快变得不可读！ 维持…是一场噩梦
这就是为什么我给SciTE添加了在#ifdef / #else / #end之间跳转的能力…在更常规的情况下它仍然是有用的。
后来，我写了一个Visual Studiomacros，一旦我们获得了我们的VCS，就快乐地摆脱旧的代码！
现在，像buti-oxa一样，有时候我觉得有必要说明为什么我删除了一些代码。 出于同样的原因，或者因为我删除了我认为不再需要的旧代码，但我不太确定（遗留，遗留…）。 显然不是在所有情况下！
实际上，我不会留下这样的评论，但是我可以理解这个需求。
更糟的是，我会在一个版本中注释掉，并删除下一个版本中的所有内容。
在我目前的工作中，对于重要的本地变更，我们离开旧的代码，但可以通过属性重新激活它，以防紧急情况发生。 经过一段时间的testing后，我们最终删除了旧的代码。
当然，VCS的评论是最好的select，但是当更改是在其他更改的大文件中的几行时，引用小的删除可能很难…
如果你处于重大变革的中间，需要对现有function进行修改，那么评论未来的代码是一件合理的事情，只要你说这是未来的function，至less在我们有期货友好的源代码pipe理系统。
我对未使用的代码发表评论，因为你永远不知道什么时候需要回退古代代码，也许旧代码可以帮助其他人理解它，如果那时更简单的话。
我同意你的意见; 海事组织这就是为什么你使用版本控制。 借助良好的签入/提交评论和差异工具，您始终可以找出为什么删除了行。
如果您正在使用任何forms的源代码pipe理，那么这种方法有点多余（只要使用描述性日志消息）
我也认为这是一个可怕的build议:)
你应该使用源代码控制，如果你删除了一些代码，你可以在提交时添加注释。 所以你仍然有代码的历史，如果你想…
有一个通用的“干净的代码”的做法，说一个人应该永远不会删除代码，因为它杂乱无章，因为你的CVS / SVN将归档它。
虽然我同意这个原则，但我并不认为这是所有发展情况的可接受的方法。 根据我的经验，很less有人跟踪代码和每次登机的所有变化。 因此，如果没有注释掉代码，他们可能永远不会意识到它已经存在。
像这样评论代码可能是一种提供即将被删除的一般性警告的方式，但当然，并不能保证感兴趣的各方会看到这样的警告（尽pipe如果他们经常使用该文件，他们将看见）。
我个人认为，正确的做法是将这些代码分解到另一个私有方法，然后联系相关的利益相关者，并在实际摆脱该function之前通知他们待处理的删除。
在我所在的地方，我们将旧代码注释为一个发布周期，然后删除注释。 （如果一些新代码有问题，并且需要用旧代码replace，那么它给了我们快速修复能力。）
在几乎所有情况下，旧代码当然应该在您的RCS中删除和跟踪。
就像所有的事情一样，我认为把“所有被删除的代码总是被删除”的说法是不正确的。
旧的代码可能会因为一个原因而被留下。 离开代码的主要原因是当你想在将来的代码段工作的任何开发人员看到旧的代码。
依靠源跟踪显然不给这个。
所以，我相信正确的答案是：
– 删除旧的代码，除非它提供了代码中的下一个开发人员需要的关键信息。 也就是说，在99％的时间内将其删除，但是不要制定严格的规则，在情况许可的情况下，您将无法为下一个开发人员提供所需的文档。
