将错误修正注释保留在代码中是否很好？

我的团队正在使用透明脚本作为版本控制。我正在从事的项目还没有开始7-8年前。在项目的整个生命周期中，我们发布了多个bug修复服务包等。使用bug跟踪系统可以跟踪问题，并且大多数从事bug修复的人员都遵循将注释包含在START /中的例程。用日期，作者，错误ID等结束块

我觉得这无关紧要，并使代码混乱且难以维护，这些都是检入注释/标签等中必须包含的内容，我们可以在其中保留工作产品的其他生命周期信息。

最佳实践是什么？

该代码的某些审阅者坚持要删除有关该错误的注释，并进行修复以简化其寿命。以我的理解，他们必须通过将文件映射到视图来审阅文件，并获取分支的更改日志并进行审阅。如果我可以将一些最佳实践提交更新的代码进行审查，将很有帮助。

将错误修正作为注释添加到代码中的问题是，您没有完整的故事。如果我看到一个完全正常的一段代码标记为“这是一个修复的错误等等 ”，我的第一反应是说“那又怎么样？”。代码在那里，它可以工作。维护代码唯一需要知道的是一个注释，它告诉我它的作用。

更好的做法是在SCM提交日志中添加错误修正引用。这样，您将看到错误是什么，在何处引入了错误，以及如何对其进行了修复。另外，当发布时间到了，您可以简单地提取SCM日志，并添加一个项目符号，指出存在错误，并且已修复。如果另一个分支或版本引入了相同的错误，则很容易找到该修补程序，如果确实是同一回事，则可以重新应用。

说了这么多，我也同意查尔斯的回答。如果某种原因的代码不明确，则一定要告诉维护者该代码是有原因的，应谨慎对待。

通常是不好的做法。我不会说永远不应该这样做。有时，您会遇到外部API中的错误（必须解决）。如果您不了解潜在的错误，则变通方法可能看起来完全死了。在这种情况下，最好将代码中的错误记录下来，这样同事或您以后的同事就不要试图“修复”明显的脑残代码。

不好的做法。注释将过时，并使代码混乱。如果需要，该信息在SCC系统的版本历史记录中仍然可用。

听起来像是不好的做法。如果您的组织决定迁移到另一个错误跟踪系统该怎么办？不要将您的产品与当前使用的工具联系得太紧。除了引用特定的错误ID，以及不清楚为什么代码看起来像的原因之外，还可以通过代码中的注释来激发您的设计决策。

我的第一反应是不要重复自己，因此将其从代码移入SCM日志。在这里，我们对功能的修订注释，作者名称以及文件和功能的创建日期进行了类似的讨论。过去（在使用SCM之前），所有这些信息都保存在文件中，以便能够重构文件的演变。

大约一半的开发人员希望此信息能够将所有信息放在一个位置（这会触发他们搜索SCM中的更改）。另一半的开发人员没有从Coe中寻找变化的线索，而是从SCM开始搜索，因此他们不需要代码中的信息。我们尚未决定如何处理这些评论。这在很大程度上取决于人们的工作方式，有些人对于离开他们的已知方法非常固执。注释掉代码块并将它们永久保留在代码中也是一样。

只是为了增加Dyaster 等人的内容。曾经说过，尽管JIRA确实具有显示与错误修正相关的更改的强大功能，但记录错误修正的绝对最佳位置是在测试用例中。如果代码不清晰，而没有注释指出已修复的错误，则为“代码异味”。就是说，如果您没有时间清理气味，则注释应引用测试用例，在此情况下，代码为什么要执行其正在做的事情应该更加明显。如果您没有时间编写测试用例来说明错误修复，则该错误尚未真正修复，只是将其推迟了。

我同意在提交消息中而不是在代码本身中添加错误修正ID。自动跟踪提交消息以获取错误ID的错误跟踪器非常有用。

另外，您可以使用版本控制系统的blame / annotate / claim命令来帮助替换这些注释。然后，当您运行以下命令时：

vcs blame file.ext

您会看到有用的信息，通常包括谁更改了每行，何时更改了行以及提交ID。从提交ID，您可以获得完整的消息，其中应包含错误ID。

好的VCS系统将让您在计算谁修改一行时忽略空白。

我不知道Clear Case有什么功能。