评论中的旧代码

Question

您应该在代码库中注释旧代码多长时间？承包商继续将旧代码保留在代码库中，将其转换为注释。这真的令人沮丧，我希望他们只删除旧代码而不是评论它。

是否有正当理由将旧代码作为注释保留在代码库中？我正在使用Visual Sourcesafe的版本控制

Answer 1

如果你使用像SVN或CVS这样的东西，没有。我会在视线中擦掉它们。它们使代码的可读性降低。

应该提供评论以帮助正在阅读代码，解释内容等的程序员。

Answer 2

我能想到的一个正当理由是这个（虚构的）例子：

# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a

基本上，要让其他开发人员不要重新插入因某种原因而删除的代码。

Answer 3

告诉承包商停止这样做。这是一种可怕的做法。

没有任何理由在代码库中保留旧代码;它只是妨碍了。您的版本控制系统将显示每个文件的历史记录。

保留旧代码的唯一可能原因可能是历史参考（可能是旧代码做了一些特别奇怪的事情，可能与当前情况有关）。

我偶尔会注释掉代码知道我暂时改变了（暂时我的意思是不到几天）并且肯定打算回去。

编辑：另一个相关的做法是在文件中添加更改的名称和日期：

// 06/20/2009 - joe changed this #1245

也不要这样做。当时看看谁做出改变似乎很有价值，但随着时间的推移，它确实没有任何价值，也使代码变得混乱。

Answer 4

如果您正在使用源控制，那么删除旧代码，因为副本将处于源代码控制准备状态，如果您需要将其添加回来，则等待您。在那里使用旧代码将降低如上所述读取代码的能力并引入混淆。此外，如果您使用承包商编写代码，请告诉他们如何编码，因为您支付他们的工资。为它们定义编码标准并按意图使它们编码，这应该改进方法，属性等的名称，并减少所有评论的需要。

Answer 5

你问“多久了？”如果那些是人们仍在工作的热点，我不会因为在一两个地方使用旧代码而感到冒犯。

也许他们对新代码没有信心。新代码“完成了吗？”这是它应该写的吗？它通过测试吗？它是否经过评论并记录在规范中？性能应该在哪里？ （我能想到的最好的理由是将旧代码和新代码放在一起，就是在我定时或分析某些案例时。）

旧代码有什么比新代码更好的了吗？

承包商是否感到匆忙？或者它只是版本控制前几天的旧习惯？

Answer 6

当你提醒承包商时，他们不必评论代码，因为Sourcesafe将保留历史记录，询问他们为什么要这样做。

可能是因为某些原因他们不相信它。如果你能从中得到这个理由，他们可能会注意。我知道多年前我们从VSS迁移的原因是它们可能已经暴露于可靠性和可伸缩性问题。如果您可以通过证明VSS足以满足您的需求或者说您将调查其他源控制解决方案（如果您当然有预算）来解决他们的顾虑，那么您应该赢得他们。

劝说胜于强迫。

Answer 7

是的，看见了。它没有给出任何其他值，以表明评论它的开发人员不确定删除它。或者他们不知道如何使用您的源代码管理软件。

Answer 8

基本上，您只有2个选项。

1. 删除它 - 当您使用某些代码存储库时。您的存储库将准确地告诉您所做的更改，因此无需在您的工作代码中保留长旧的注释，这无法用简单的语言解释。
2. 另一方面，如果您希望保留该代码有几个原因，例如，我在我的应用程序中保留了一些浮点计算代码注释掉，因为它无法在平台上运行，我正在编程。但由于我不希望我的应用程序仅限于该平台，因此我将代码保留在那里，因此当我将应用程序移植到支持浮点计算的平台时，它可以节省大量工作。 这只是保留旧代码的原因之一，可能适用于相同背景的人。

否则，上面提到的是你唯一的两个选择。你的电话!!

Answer 9

保留旧代码只会使整个代码的读取变得更加困难。只要项目存在某种形式的版本控制，就应该删除注释掉的代码。如果您没有版本控制并且无法设置，则建议将旧代码放在某个不属于代码库的文件中。

Answer 10

我假设你引用了看似有价值的重要代码块，或者它们本身就是好的算法，而不仅仅是这里或那里的奇数行。

在这些情况下，如果您进行了大量更改而保留了旧代码，那么保留代码的风险很明显，因为注释可以作为代码审查的一种形式。获得最新版本的任何人都可以立即看到所做的大改动，如果出现问题，可以更容易地看到过去的情况。如果问题出在新代码上，那么有一种非常简单的方法可以立即检查它。

因此，考虑到这一点，我倾向于为第一次修订注释掉旧代码，然后只在代码随后再次更改时删除它，此时此更改将被“填入”并且不太可能是导致错误的原因。

这些评论是一种文档形式，没有必要删除任何纯粹的“干净”编码理想。当它们不再需要时将它们移除，保留它们可能是有价值的。

Answer 11

首先，我说要摆脱它。

但是我知道有一个原因：虽然它仍然存在于你的版本控制中，但这并不意味着任何人都可以看到它。如果您可能需要再次查看它，首先必须知道它曾经存在过。有时你做了一个修改，未来的开发人员需要看到旧的和新的方式，如果你删除旧的方式，开发人员如何知道它曾经存在？大多数人都没有很好地记录版本控制中的变化以解决这类问题。

Answer 12

将旧代码留在那里有很多理由。基本上 - 一旦它被删除它实际上已经消失 - 除非有人真的记得它在那里。

作为一个邪恶的承包商，我不会删除代码，除非我正在大量重写一个程序 - 删除它并替换它而不是“修复”它。

Answer 13

我目前正在介绍的项目，使用另一种方法 - 某种妥协......当你决定不再使用某些部分代码时，你只需将其注释掉，写下日期注释掉，并且（如果有可能 - 例如在Netbeans或VisualStudio中）将旧代码插入#region OLD_IMPL中。影响？ - 为了以防万一你还有一个旧代码 - 未使用的代码块正好占用1行（#region OLD_IMPL） - 如果你看到，该代码一年没有使用（你有评论日期），你可以简单地删除它。

如遇任何危急情况，您总是使用SVN;）

Answer 14

那些说因为版本控制工具可以解决你可能遇到的任何问题而放弃注释掉代码的人都是白痴。

你需要摆脱过时的代码，一旦你确定它真的被废弃了。

曾经不得不修改修改，因为“它并不完全是坏事，但唉它也不完全好”？如果您仍然可以取出生产源并知道以前版本的代码仍然在那里，以某种文本形式，它将为您节省大量时间，因为您不需要诉诸复杂，难以 - 控制因此使用您的版本控制工具可能为您提供的任何“部分源合并”和“部分源合并”的非常错误的过程。

那些不喜欢这种现实的人肯定必须花费他们的整个职业生产的代码从来都不是“不完全糟糕，但也不是完全好”，换句话说，只产生完全不好的代码或否则完全完美。我们都知道实现后者的可能性有多大。