维护评论

Question

修改现有代码时使用了哪些特殊技术？

例如：假设您修改方法中的业务规则。您是否使用特殊注释标记修改后的部分？

修改代码时使用的任何编码/评论标准？

Answer 1

你的意思是：

foo();  // changed by SecretWiz, 20090131

我不推荐这个。它使代码文件变得混乱，版本控制系统应该为您处理。它记录了谁改变了什么。使用

svn blame

Answer 2

如果我做了类似修复一个相对模糊的bug的事情，基本上任何事情都不清楚为什么我按照我的方式编写代码，我通常会添加注释来解释它，以便我（或某人）否则，如果其他人修改过我的代码;-)以后不会意外删除它。

Answer 3

我总是尝试做的一件事是在我为此更改做的代码检查注释中将错误ID（或功能请求ID）放入错误跟踪系统中。我添加了类似“在bugzilla中查看此错误/功能的注释以获取更多详细信息”。在那里，我可以并且通常解释代码更改的基本原理。这意味着需要通过功能请求/错误ID跟踪所有更改或至少所有重要更改。我有很多次创建了一个错误，只是为了详细解释所涉及的业务原因。

Answer 4

不，这是一个非常糟糕的主意。源代码管理会保留所有编辑的历史记录。如果您还想要其他内容，请在您的错误跟踪工具中输入一个条目。没有必要注释掉旧的代码部分，或者使用以下内容将其丢弃：

// modified by A.B. on 11/23/99 to fix issue #123456

我已经在我们的代码库中看到过这样的评论，他们几年没有任何意义。究竟是谁A.B。，问题是什么＃123456？如果代码仍在此处，这是否意味着有人计划在将来推回这些更改？

这些评论没有任何价值，只会使您的代码混乱。

Answer 5

我建议创建一种方法＆amp;从正在修改的代码中调用它 另外，将方法命名为建议方法的目的/意图。

e.g。 GiveRebateIfValidCoupon();

Answer 6

“修改代码时使用的任何编码/评论标准？”

是。创建新的子类。保留旧代码，除非在极少数情况下你没有正确测试它并且实际上是错误的。

对需求的更改意味着添加子类和新测试来处理新的业务规则。

Answer 7

我唯一一次添加特别评论的意思是修改是暂时的。在那种情况下，我用标准关键字（例如，TEMPFIX）标记它，以便我以后可以找到它。当然，您必须记得回来删除代码或进行永久性更改，但在某些项目中，我们强制执行使用允许我们指定过期日期的宏，之后代码停止编译。

除此之外，我们依靠源代码控制。

Answer 8

代码应符合您拥有的编码标准或您的组织。

所以，不，不应该有任何特殊的评论，代码已被修改 - 所有或至少大多数代码迟早会被修改。

如果您继承的代码与评论标准不符，那么请务必在refactor代码中添加评论。如果代码真的很旧且没有文档，那自然就意味着添加文档。

在修改代码之前理解代码是很好的（顺便说一下）。

Answer 9

通常我只会更改代码并在我的源代码管理中签入我的注释。在所选的任务跟踪工具中，您可以参考实现任务的修订版。

有时我知道某些功能会来回变换，移动，更改名称等等，具体取决于用户要求的争论方式。在这个特殊情况下，我会将旧版本保留在那里，然后将其评论出来。然后，稍后取消注释它变得微不足道，而不是通过源代码控制来寻找旧版本。如果他们以后必须维护您的代码，这也可以节省某人的屁股，因为当用户改变他们的想法时，该要求将已经在代码中，等待取消注释。

Answer 10

我必须同意很多其他人的意见。 “如果您的代码中不需要某些内容，请将其删除”。特别是在生产代码中，你想要的最后一件事就是混乱。有人可以更容易地弄清楚你的改变是如何工作的，而不是阅读你的维护评论，可能会感到困惑。

我曾经在我的项目中保留旧的弃用代码，但随着时间的推移，一个应该只有几千行的项目最终超过10,000，难以管理。