Question

我在遗留系统上工作，我曾经看过源代码中每个版本都修改过的文件或函数的修订历史记录，例如：


//
// Rev. No     Date      Author   Description
// -------------------------------------------------------
//   1.0    2009/12/01   johnc    <Some description>
//   1.1    2009/12/24   daveb    <Some description>
// -------------------------------------------------------
void Logger::initialize()
{

    // a = b;             // Old code, just commented and not deleted
    a = b + c;            // New code

}

我只是想知道今天许多人是否仍然采用这种记录历史的方式？如果是，您如何对源代码应用修改 - 您是评论它还是完全删除它？

如果没有，记录这些修订的最佳方法是什么？如果您使用版本控制系统，那么源文件是否包含纯源代码，必要时除了注释（每个函数没有修订历史记录等）？

Answer 1

只需依靠您的版本控制系统。是的，只是纯粹的源代码。如果代码被注释掉，我将其删除。如果我不确定我是否会留下TODO评论。我不会在源中但在提交消息中插入引用注释的注释。您不需要在代码中记录它过去的样子。

Answer 2

手动修订历史很难维护，因此几乎总是过时的。

我相信修订控制系统能够提供这些信息。除了正确之外，它可以更加精确，例如使用预行注释（最后一行更改了该行）。

当我觉得有必要时，我会直接在源代码中的bug跟踪系统中插入注释，即使这些信息在提交消息中也可用。

每个项目（不是每个源文件）都有一个更改/发布说明文件是有意义的，该文件是为每个版本手动维护和更新的。

Answer 3

现在记录这些修订版的最好方法是让你的版本控制执行它，但这也意味着你必须强制执行开发人员编写有意义的提交注释的规则，或者至少一些错误跟踪数字，所以它将是很容易弄清楚他们为此做了什么。

Answer 4

我从未在代码评论中看到修订历史记录。我最多看到Javadoc @version标签来记录版本。最旧的版本控制方法是这样的： logo2007-1.png, logo2007-2.png

版本控制应该是最佳解决方案。

另见：http://betterexplained.com/articles/a-visual-guide-to-version-control/

Answer 5

我曾经在一家公司工作，该公司要求对所有进入数据库的SP发出此类评论。我发现它需要进入我们的源控制系统，这令人难以置信的冗长和冗余。

内联注释的主要用途是验证新环境的部署是否成功（如生产）。这也是一个繁琐的过程，只是因为没有其他方法而被使用。

我从来没有在其他任何地方找到像这样的内联评论的用途，发现它们只会导致繁琐的头痛导致工作。

我会提倡一个系统，其中源代码控制管理注释和修订历史而不是代码。这是系统的目的之一，也是最好的选择。 IMO。

修订历史记录和记录更改

5 个答案: