好的，这件事在我目前的工作中引起了一些摩擦，我真的没想到。有组织的内部软件开发是一个新概念，我已经制定了一些编码指南的初稿。
我建议永远不要将“注释掉”的代码检入存储库。我之所以这样说的原因是存储库保存了文件的完整历史记录。如果要删除功能代码，请将其完全删除。存储库会保留您的更改，以便更容易查看更改内容。
这引起了一些摩擦，因为另一位开发商认为采取这种方式过于严格。这位开发人员希望能够注释掉他正在处理但尚未完成的一些代码。然后，此代码将永远不会被签入，然后不会保存在任何地方。我们将使用TFS，因此我建议搁置更改将是最正确的解决方案。然而，它并未被接受，因为他希望能够检查可能部署或未部署的部分更改。
我们希望最终能够充分利用持续集成并自动部署到开发Web服务器。目前没有Web服务器或数据库服务器的开发版本，但很快就会更改。
无论如何，你有什么想法？您是否认为“注释掉”代码对存储库有用？
我非常有兴趣听取其他人的意见。
编辑： 为清楚起见，我们不使用私有分支。如果我们这样做，那么我会说你的私人分支做你想要的，但不要将已注释的代码与主干或任何共享分支合并。
编辑： 我们没有使用私有或每个用户分支的正当理由。这不是我不同意的概念。我们还没有这样设置。也许这是最终的中间立场。现在我们使用TFS搁架。
答案 0 :(得分：122)
可能有其他人有不同的经历，但在我的检查半完成代码是一个可怕的想法，期间。
以下是我学习并尝试遵循的原则：
这意味着：
总而言之，不！如果代码还没有准备好进入下一阶段（无论哪个是你的：IntTest / QA / UAT / PreProd / Prod），它不应该提交给主干或多开发人员分支。周期。
编辑：在阅读完其他答案和评论后，我会补充一点，我认为禁止评论代码并不一定是个好主意（不知道你是怎么强制执行的） 。我要说的是，你应该让团队中的每个人都按照我上面描述的理念购买。我工作的团队全心全意地接受它。因此，源代码管理是一个没有结果的团队成员，可以帮助我们完成工作。
不接受这种哲学的人通常会导致broken windows并且经常受到源控制的挫败。他们认为这充其量是一种必要的邪恶，最糟糕的是要避免;这导致不常见的签到，这意味着变更集是巨大的，难以合并，这会使人感到沮丧，使签到的东西更加难以避免等等。这最终是一种态度，而不是真正的过程。对它提出心理障碍很容易;很容易找到原因，为什么它不起作用，就像你很容易找到不节食的理由，如果你真的不想。但是当人们做想要这样做并且致力于改变他们的习惯时，结果是戏剧性的。你有责任有效地出售它。
答案 1 :(得分：43)
“从不”在指南中很少使用。
您的同事有一个很好的例子，说明何时检查已注释掉的代码可能是合适的：当它不完整时如果在活动时签入则可能会破坏应用程序。
在大多数情况下，在管理良好的变更控制系统中，无需注释掉死代码。但是，并非所有评论的代码都“死了”。
答案 2 :(得分：24)
为了维护历史记录，永远不会签出注释掉的代码。这是源头控制的重点。
人们在这里谈论很多理想。也许与其他所有人不同，我必须在多个项目中工作，“真实世界”偶尔会打断我的工作日。
有时，实际情况是，我必须签入部分完整的代码。它可能会丢失代码或签入不完整的代码。无论多么小，我都无法承担“完成”任务的费用。但是如果没有签入所有代码，我将不将我的笔记本电脑与网络断开连接。
如有必要，我将创建自己的工作分支以提交部分更改。
答案 3 :(得分：23)
我留下注释掉代码的一个案例：
// This approach doesn't work
// Blah, blah, blah
当这是问题的明显方法但它包含一些微妙的缺陷。当然，存储库可以拥有它，但是存储库不会在将来警告任何人不要走这条路。
答案 4 :(得分：18)
我肯定会强烈地劝阻检查注释掉的代码。但是，我不会绝对禁止它。 有时（如果很少）将检出的代码检查到源代码管理中是合适的。说“永远不会那样”是限制性的。
我认为我们都同意这些观点：
有些人说还有其他类别，例如暂时删除的代码，或者增量但不完整的改进，其中包含少量已注释掉的代码作为下一步的文档，或者非常短（理想情况下为1行）注释掉的代码片段，显示应该永远重新添加的内容。注释掉的代码应该总是附有一个注释，说明为什么它被注释掉（而不仅仅是删除）并给出注释掉的代码的预期生命周期。例如，“下面的代码弊大于利，因此被注释掉了，但需要在发布XXX之前进行替换。”
如果您提供修补程序以阻止客户流血并且您没有立即找到最终解决方案的机会，则上述评论是合适的。发布修补程序后，注释掉的代码提醒您仍然需要修复。
我何时签入已注释掉的代码？一个例子是当我暂时删除某些东西时，我认为很有可能在不久的将来以某种形式重新添加。已注释掉的代码可以直接提醒您这是不完整的。当然，旧版本在源代码管理中，您可以使用 FIXME 注释作为标记，表示需要更多内容。但是，有时（如果不经常）代码是更好的评论。
此外，当通过删除一行（或更少，两行）代码来修复错误时，我有时只会注释掉带有注释的行 never 重新启用该行代码有原因。这种评论清晰，直接，简洁。
Rex M说：1）只检查完整功能，2）[如果]任务太大 - 将其分解为较小的可完成任务。
回答：是的，这是理想的。有时，当您处理生产代码并且需要立即解决关键问题时，这两个选项都无法实现。有时为了完成一项任务，您需要在该字段中放置一段代码一段时间。当您尝试查找问题的根本原因时，对于数据收集代码更改尤其如此。
对于在更一般的问题中被询问的特定实例...只要开发人员将注释掉的代码检查到私有分支中，除了该开发人员之外没有人会看到（也许开发人员正在合作的人）与），它没有什么害处。但是，开发人员应该（几乎）永远不会将此类代码提供给主干或等效代码。 Trunk应该始终构建并且应该始终运行。向trunk提供未完成的代码几乎总是一个非常糟糕的主意。如果您让开发人员将未完成或临时代码检入专用分支，那么您必须依赖开发人员在交付到主干之前不要忘记清除代码。
为了澄清对其他答案的评论，如果代码被注释掉并签入，我期望代码将在未注释的情况下运行，并且代码被注释掉了。显然，重构工具并不总是在重构中包含注释。几乎总是，如果我把注释掉的代码投入生产，代码就可以作为一个精致的评论，比散文更具体，需要在那里做一些事情。它不应该有很长的寿命。
最后，如果您可以在每个源文件中找到已注释掉的代码，那么就会出现问题。将注释掉的代码传递到主干任何原因应该是罕见的事件。如果经常发生这种情况，那么它就会变得混乱而失去价值。
答案 5 :(得分：15)
我认为从不是一个太强大的条件。
我倾向于评论，签到，运行测试，进行思考，然后在下一个版本发布后删除评论。
答案 6 :(得分：14)
通常，签入注释掉的代码是错误的，因为它会使那些不是原作者并需要阅读或修改代码的人产生混淆。无论如何，原作者在3个月过后经常会对代码感到困惑。
我支持这样的信念，即代码属于公司或团队，并且您有责任让同事轻松完成任务。签入注释掉的代码而不添加关于它被保留的原因的评论等于说：
我不介意你是否最终结束 混淆了为什么这个东西在这里。 我的需求比你的更重要 这就是为什么我这样做了。我做 不觉得有任何理由需要证明 对你或其他任何人，为什么我有 完成了这个。
对于我来说，注释掉的代码通常 >
答案 7 :(得分：6)
当您需要添加一个小功能或错误修复时，在接下来的3分钟内，你必须修复一个文件，你有一些半开发的代码，我说它没关系，实际需要统治实用的理想战场。
答案 8 :(得分：6)
我大致同意不应该检查注释掉代码的原则。源代码控制系统是一个共享资源，你的同事在某种程度上将它用作他的个人便笺簿。这对其他用户来说并不是很体贴，特别是如果您订阅了代码库共享所有权的想法。
下一个看到注释掉的代码的开发人员不会知道它正在进行中。他可以自由改变吗？这是死代码吗？他不知道。
如果您的同事的更改未处于可以签入的状态，则需要完成更改，和/或学习进行更小的增量更改。
“检查可能部署或未部署的部分更改” - 可能也意味着可能会或可能不会进行测试？对于一个非常冗长的代码库来说，这是一个滑坡。
答案 9 :(得分：5)
这显示了两种思想流派的根本区别：那些只检查工作代码，他们感到满意和感觉值得保存的人，以及那些检查他们工作的人，所以修改控制是为了支持他们反对数据丢失。
我将后者描述为“那些喜欢使用他们的版本控制系统作为穷人的磁带备份的人”，但这对于我所在的营地来说真的很不错。： - ）
我的猜测是你是“好代码”阵营，他是“工作代码”阵营。
[编辑]
从评论中，是的，我猜对了。
就像我说的那样，我和你在一起，但我尽可能地说这是一个少数意见，无论是在stackoverflow还是在我工作的地方。因此，我认为您不能真正将其作为唯一的运营方式纳入您的开发标准。如果你想要遵循标准，那就不是了。一个好的领导者知道的一件事是永远不会发出他们知道的命令将不会被遵循。
btw：好的编辑器将有助于保留旧版本。例如，在Emacs中，我将keep-old-versions和keep-old-versions设置为10，这样可以保留我文件的最后10次保存。您可以将其视为一种帮助您反对修订控制备份人群的方法。但是，你永远不会赢得这场争论。
答案 10 :(得分：4)
根据我的经验，开发人员交换机已注释掉代码。
有时，新的后端是并行构建的，激活开关在源代码控制中被注释掉。
我们在蓝色的月球上需要一些奇怪的功能，但客户不会需要通常以这种方式实现。这些东西通常具有高安全性或数据完整性绕过的风险，因此我们不希望它们在开发之外活动。要求开发人员首先使用它取消注释代码似乎是获取代码的最简单方法。
答案 11 :(得分：4)
签入注释掉代码的另一个原因：
您正在修改现有代码，并发现了一个微妙的错误，容易被忽视，甚至可能在第一眼就看起来正确。将其注释掉，将修复程序放在其位置，并为正在进行的操作添加注释，以及为何修改它。检查是否存在，以便您对修复程序的注释位于存储库中。
答案 12 :(得分：3)
这里真正的问题可能是开发人员是否应该被允许签入不完整的代码？
这种做法似乎与您实现持续整合的既定目标相矛盾。
答案 13 :(得分：3)
这取决于。如果它被留在那里是为了说明，也许。它可能在重构期间很有用。否则，一般来说，没有。另外，注释掉未完成的代码必然既容易出错又有时间下沉。更好的是，他将代码分解成更小的部分，并在它们工作时检查它们。
答案 14 :(得分：3)
我的观点：如果开发人员在他们自己的分支机构或他们自己的沙箱区域工作，那么他们应该能够检查他们想要的任何内容。当他们将代码检查到共享分支（功能分支，或团队的分支，或者当然是MAIN / trunk）时，代码应该尽可能保持原始状态（没有注释掉的代码，没有更多的FIXME等）。
答案 15 :(得分：2)
我认为注释掉的代码被认为是“浪费”。
我假设您在团队环境中工作。如果您正在自己工作，并且用“todo”注释掉代码，那么您将回到它，那就不同了。但是在团队环境中，您可以放心地假设一旦注释掉了代码，就会留下它，这很可能会导致更多的痛苦而不是满足。
如果您正在进行同行代码审查，那么它可能会回答您的问题。如果其他开发人员审核了您的代码，并说“为什么这个注释掉的代码试图'哇''，那么您的代码未能通过代码审查，您无论如何都不应该检查它。
注释掉的代码只会向其他开发人员提出问题 - 因此浪费时间和精力。
您需要提问“为什么”这个代码被注释掉的问题。一些建议：
如果您因为“不确定业务规则”而对代码进行评论，那么您可能会遇到“范围蔓延”的问题 - 最好不要使用“我们很高兴但我们不喜欢”的要求来破坏您的代码库。有时间实施“ - 用清晰的代码保持清洁，并测试实际存在的内容。
如果您正在评论代码，因为您“不确定它是否是执行此操作的最佳方式”，那么请让您的代码进行同行评审！时代在变，你会看到你今天写的代码2年，并认为它太可怕了！但你不能四处评论那些你知道可以做得更好但你现在找不到办法的东西。让长期维护代码库的人确定是否有更好的方法 - 只需编写代码，测试并运行代码并继续前进。
如果您正在评论代码，因为“某些内容不起作用”，那么FIX IT！常见的情况是"broken tests" or "todo's"。如果你有这些，你可以通过修复它们或者只是去掉它们来为你的成员节省很多时间。如果他们可以被“打破”一段时间，他们很可能永远被打破。
所有这些潜在的场景（以及我此处未提及的场景）都浪费了时间和精力。注释掉的代码可能看起来像一个小问题，但可能是团队中更大问题的一个指标。
答案 16 :(得分：2)
允许源代码控制历史记录说明做某事的“旧方法”而不是将其评论出来，并在结论中检查注释以及解释是一个好主意。
然而，在现实世界中，没有人会查看他们正在处理的文件的源代码控制历史，除非它是某种官方审核流程的一部分（仅定期完成），或者如果某些内容不起作用，并且开发人员无法弄清楚原因。
即使这样，回顾超过3个版本基本上也不会发生。
部分原因是因为源控制系统不容易进行这种随意评论。通常你必须查看一个旧版本或旧版本的差异，你只看到两个版本，并且没有很好的简洁视图，可以让你一目了然地了解改变的内容。
部分地，它是人性与团队需求的结合。如果我必须修复一些东西，并且我可以在几个小时内修复它，我不太可能花一个小时来调查一个月内没有“实时”的旧版本代码（每个开发人员检查一次）通常意味着支持许多修订），除非我碰巧知道那里有什么东西（例如我记得有关改变与我现在正在做的事情有关的事情的讨论）。
如果代码被删除并重新签入，那么，出于所有意图和目的（除了完全回滚的有限目的），它就不复存在了。是的，它是出于备份目的，但没有一个人担任代码库的角色，它会迷失方向。
我当前项目的源代码控制树大约有10周大，在一个只有大约4名工程师的团队中，大约有200个已提交的更改列表。我知道我的团队并没有做好工作，因为一旦有了可靠的东西，就应该立即办理入住手续。这使得依赖于读取代码的每个部分的代码历史来捕获每个重要的变化都非常粗糙。
现在，我正在开发一个初始开发模式的项目，这与维护模式下的项目非常不同。在这两种环境中都使用了许多相同的工具，但需求相差很大。例如，通常有一项任务需要两个或更多工程师密切合作来构建某些东西（比如客户端和某种类型的服务器）。
如果我正在编写服务器，我可能会编写客户端将使用的草稿界面的代码并将其检查完全无法正常运行，以便编写客户端的工程师可以更新。这是因为我们的政策规定，将代码从一个工程师发送到另一个工程师的唯一方法是通过源代码管理系统。
如果任务需要花费足够长的时间，那么为我们两个人工作可能值得创建一个分支（虽然这违反了我组织中的政策 - 工程师和个人团队负责人没有源控制服务器上的必要权限）。最终，这是一个权衡，这就是为什么我们尽量不制定太多“永远”或“永不”的政策。
我可能会回应这样一个没有评论代码的政策，说它有点幼稚。也许是善意的，但最终不太可能实现其目的。
虽然看到这篇文章将要回顾我上周检查过的代码，并删除已经完成的注释掉的部分（虽然它有效）但也永远不会再被期待了。
答案 17 :(得分：2)
我认为在源代码控制系统中检入注释代码应该非常谨慎，特别是如果用于注释代码的语言标记是用块写的，即：
/* My commented code start here
My commented code line 1
My commented code line 2
*/
而不是基于单独的行，例如：
// My commented code start here
// My commented code line 1
// My commented code line 2
（你明白了）
我非常谨慎的原因是，根据技术的不同，您应该非常小心您正在使用的差异/合并工具。使用某些源代码控制系统和某种语言，差异/合并工具很容易混淆。例如，ClearCase的标准差异/合并对于合并.xml文件来说是非常糟糕的。
如果发生注释阻止行没有正确合并，那么在不应该的情况下，代码将在系统中变为活动状态。如果代码不完整并打破构建，那可能是最不邪恶的，因为你会立即发现它。
但是如果代码通过构建，它可能会在它不应该存在时变为活动状态，并且从CM的角度来看，这可能是一个噩梦场景。 QA通常测试应该存在什么，他们不测试不应该存在的代码，所以你的代码可能在你知道它之前就已经开始生产了，并且当它被实现时它的代码就在那里了。不应该，维护成本增加了许多倍（因为“错误”将在生产中或客户，最糟糕的地方或时间发现）。
答案 18 :(得分：2)
我绝对同意不应将注释掉的代码检入存储库，这就是源代码控制的用途。
根据我的经验，当程序员检查注释掉的代码时，这是因为他/她不确定什么是正确的解决方案，并且更乐意将备用解决方案留在源中，希望其他人做出决定。
我发现它使代码复杂化并使其难以阅读。
我检查已完成的一半代码（因此您获得了源代码管理的好处）没有问题，而实际系统没有调用它。我的问题是找到评论代码的部分，但没有解释导致代码被排除的困境。
答案 19 :(得分：2)
我认为“从不”太强大了。我投票给人们留下一些个人余地，看看人们是否将注释代码检入存储库。最终目标应该是编码器生产力，而不是“原始存储库”。
为了平衡这种松懈，请确保每个人都知道注释掉的代码有一个到期日期。任何人都可以删除已注释的代码，如果它已经存在整整一周且从未激活过。 （将“一周”替换为任何对你感觉合适的东西。）这样，你保留了在看到它时杀死杂乱的权利，而不会过分干扰人们的个人风格。
答案 20 :(得分：1)
在1）提前检查和2）始终将存储库保持在工作状态之间存在明显的紧张关系。如果你有不止一些开发人员，后者将会越来越优先，因为你不能让一个开发人员为了他自己的个人工作流而遍布其他所有人。 那说，你不应该低估第一条准则的价值。开发人员使用所有不同类型的心理栅栏，个性化的工作流程是伟大的开发人员挤出这些额外的X的一种方式。作为一名经理，你的工作不是试图理解所有这些细微差别 - 除非你是一个天才并且你的所有开发人员都是白痴，否则你将失败 - 而是让你的开发人员成为他们通过自己决策制定的最佳人选。
您在评论中提到您不使用私人分支机构。我的问题是你为什么不呢？好吧，我对TFS一无所知，所以也许有充分的理由。然而，在使用git一年后，我必须说一个好的DVCS完全扩散了这种紧张。在某些情况下，我发现评论代码是有用的，因为我正在构建一个替代品，但如果我在其他人身上施加它，我将失去它的睡眠。能够在本地分支意味着我可以为我的个人流程保留有意义的提交，而不必担心（甚至通知）临时混乱的下游开发人员。
答案 21 :(得分：1)
回应合唱。不惜一切代价劝阻这一点。它使得代码更难以阅读，并让人们想知道那些甚至不是当前应用程序的代码的好/坏。您始终可以通过比较修订来查找更改。如果有一些大手术并且代码被大量注释掉，开发者应该在签入/合并的修订说明中注明它。
不完整/实验代码应该在一个分支中开发完成。头/行李箱应该是总是编译的主线，并且是什么运输。一旦实验分支完成它/接受它应该合并到头/主线。如果您需要支持文档，甚至还有IEEE标准（IEEE 1042）描述这一点。
答案 22 :(得分：1)
存储库是代码的备份。如果我正在处理代码但尚未完成，为什么不将它注释掉并在一天结束时检查它。这样，如果我的硬盘在一夜之间死亡，我将不会失去任何工作。我可以在早上查看代码，取消注释并继续使用。
我评论它的唯一原因是因为我不想打破隔夜构建。
答案 23 :(得分：1)
“Scar Tissue”就是我所说的已注释掉的代码。在广泛使用版本控制系统之前的几天，Code Monkeys会在文件中留下注释掉的代码，以防它们需要恢复功能。
唯一可以接受登记“疤痕组织”的是
＃4几乎没有任何借口，因为有许多免费提供且功能强大的VCS系统Git being the best example。
否则，只需让VCS成为您的存档和代码分发者。如果另一个开发人员想要查看您的代码，请通过电子邮件向他发送差异并让他直接应用他想要的内容。无论如何，合并并不关心两个文件的编码为何或如何分散。
因为它是代码，所以疤痕组织甚至比写得好的评论更令人分心。作为代码的本质，你让维护程序员花费心理cpu周期来确定疤痕组织是否与他的变化有关。疤痕是一周大还是十岁并不重要，在代码中留下疤痕组织会给那些必须对代码进行解密的人带来负担。
[编辑] 我补充说，有两个主要方案需要区分：
对伤疤组织说“不”！
答案 24 :(得分：1)
我更希望看到可能已损坏，可访问的代码，但尚未使用但尚未通过完全不可用的相同代码进行检查。由于所有版本控制软件都允许某些与主干分离的“工作副本”，因此使用这些功能确实是一个更好的主意。
新的非功能性代码在主干中很好，因为它是新的。它可能不会破坏任何已经有效的东西。如果它确实破坏了工作代码，那么它应该只是进入一个分支，以便其他开发人员可以（如果他们需要）检查该分支，看看有什么坏了。
答案 25 :(得分：0)
我认为检入注释掉的代码应该是有效的，因为新的更改通过了测试，看看之前的内容可能更有帮助，看看新的更改是否真的有所改进。
如果我必须返回多个版本才能看到现在导致性能下降的早期更改，那么这将非常烦人。
有时，注释掉的代码是一个很好的历史记录，但是，请将代码注释掉的日期放在一起。之后，在那附近工作的人可以删除已注释掉的代码，因为它已被证明不需要。
知道谁评论了这些代码也是一件好事，这样如果需要一些理由，那么就可以问他们。
我更喜欢编写新功能，确保单元测试通过，检查，然后允许其他人使用它，看看它是如何工作的。
答案 26 :(得分：0)
一个很好的折衷方案是编写一个小工具，将已签出/修改过的文件转储到网络备份驱动器。这样，您可以修改心脏的内容并备份您的工作，但您无需检查实验或未完成的代码。
答案 27 :(得分：0)
如果开发人员已经注释掉了一些代码，因为它还没有完成，那么处理这个代码的正确“源代码控制”方式是让开发人员将它保存在他自己的单独分支中，直到该代码< em> 准备办理登机手续。
使用DVCS（如git，bazaar或mercurial）这很容易，因为它不需要更改中央存储库。否则，也许您可以谈论如果开发人员在服务器上开发自己的分支，如果他们正在处理将需要足够长时间（即几天）的特定功能。
在某些情况下检入注释掉的代码没有任何问题，只是这种情况可能有更好的方法，因此开发人员可以跟踪对其源的更改，即使< / em>尚未准备好将其签入主存储库。
答案 28 :(得分：0)
显然，签入注释掉的代码的开发人员应该在一个单独的分支中工作，并根据需要合并来自主干分支的更改。
VCS系统可以帮助开发人员完成这个工作流程（git是一个非常出色的VCS系统。）
答案 29 :(得分：0)
在C ++中，我使用#if 0作为注释代码并发现它是合法的。 重构工具仍然适用于它，因此从技术上讲它几乎可以维护。而且，语法高亮显然是着色。
我认为这样的功能对所有人都有用：
如果没有真实评论解释这段代码有什么特别之处，那么请务必删除评论代码，尽管这些代码无法运行，但为什么它如此重要。
答案 30 :(得分：0)
我不知道 - 在我做出更改之前，我总是将原始行注释掉 - 如果我改变主意，它会帮助我恢复它们。是的，我会检查它们。
但我会删除之前签到的旧评论代码。
我知道我可以查看差异日志，看看有什么变化，但这很痛苦 - 很高兴看到代码中的最后一次更改。
答案 31 :(得分：-1)
我认为注释掉代码有更好的选择。
允许其他开发人员签入临时代码或实验代码的一个选项是让每个开发人员#defines（假设您正在使用支持它的语言）。
我曾经在每个编码器都有自己的#define的地方工作，匹配他们的用户名，他们可以用它们只对他们感兴趣的东西。最后当代码准备好黄金时间时，＃if检查是除去。
例如你可能有
#if JOEBLO
// This code is experimental
// ... code goes here ...
#endif // JOEBLO
关于Rex M's answer，我认为有时候你想要进行的增量登记（记录进度）不能很好地为每个人启用。在这种情况下，＃define很有用。
另一种选择是在本地使用像Mercurial这样的DVCS来跟踪你的变化，然后当你找到一个稳定的“为公众做好准备”状态时，你将这些变化推送给团队。但要小心一次提交太多。