5
Q
维护评论
A
回答
14
你的意思是这样的：
foo(); // changed by SecretWiz, 20090131
我不会推荐。它混淆了代码文件，版本控制系统应该为你处理。它跟踪谁改变了什么。使用
svn blame
2
不，这是一个非常糟糕的主意。您的源代码管理记录了所有编辑的历史记录。如果你想要别的东西，在你的bug跟踪工具中输入一个条目。有没有必要注释掉的代码或垃圾旧它与节状的东西：在我们的代码库这样的
// modified by A.B. on 11/23/99 to fix issue #123456
我见过的意见，他们就没有任何意义年下来就行了。谁是A.B.，什么是问题＃123456？如果代码仍在这里，这是否意味着有人计划在未来再次推出这些更改？
这些评论没有价值，只会让你的代码混乱。
1
我会建议创建一个方法&从正在修改的代码中调用该方法。
此外，请指出建议方法的目的/意图的方法。
例如 GiveRebateIfValidCoupon();
0
“修改代码时使用的任何编码/注释标准？”
是的。创建新的子类。除非您没有正确测试并且实际上是错误的罕见情况，否则请留下旧代码。
对需求的更改意味着要添加子类和新测试来处理新的业务规则。
0
我唯一加入特别意见的时间是修改意图是暂时的。在这种情况下，我用标准关键字（例如，TEMPFIX）标记它，以便稍后可以找到它。当然，您必须记得回来并删除代码或进行永久性更改，但在我们实施的一些项目中，使用允许我们指定代码停止编译之后的过期日期的宏。
除此之外，我们依赖源代码管理。
0
该代码应符合您拥有的或您的组织拥有的任何编码标准。
所以，不应该有任何特别的意见，代码已被修改 - 所有或至少大部分代码迟早会被修改。
如果您继承的代码不符合评论标准，那么通过一切手段添加注释，如您的代码refactor。如果代码真的很老并且没有文档，自然就意味着要添加文档。
在修改代码之前（通过这种方式）理解代码是很好的。
0
通常我会更改代码并在我的源代码管理中签入我的意见。在选择的任务跟踪工具中，您可以参考实施任务的修订版本。
有时我知道某些功能会来回改变，四处移动，更改名称等，具体取决于用户需求的讨论方式。在这种特殊情况下，我会将旧版本保留在那里，并将其注释掉。那么稍后取消注释就变得微不足道了，而不是通过源代码控制来寻找旧版本。如果他们必须稍后维护您的代码，这也可以节省某人的屁股，因为当用户改变主意时，再次需求已经在代码中，等待被取消注释。
0
我不得不同意这里的很多其他人。 “如果你不需要代码中的东西，请将其删除”。特别是在生产代码中，你最不想要的是混乱。有人可能更容易弄清楚你的改变如何工作，而不是阅读你的维护评论，并且可能会感到困惑。
我曾经在我的项目中保留旧的不推荐使用的代码，但随着时间的推移，一个只有几千行的项目最终超过了10,000，难以管理。
4
如果我要修复一个相对模糊的bug，基本上任何不明显的地方，为什么我按照自己的方式编写代码，我通常会添加一条注释来解释它，以便我（或别人，如果其他人曾经修改我的代码;-)以后不会意外删除它。
3
我一直试图做的一件事就是在代码签入注释中为错误跟踪系统中的错误ID（或功能请求ID）添加注释。我添加了一些内容，如“在bugzilla中查看此bug /功能的注释以获取更多详细信息”。我可以并且通常会解释代码更改的基本原理。这意味着所有更改或至少所有重要更改都需要通过功能请求/错误ID进行跟踪。我多次创建了一个错误，只是为了详细解释涉及的商业原因。
+1击败我第二个...... – 2009-02-01 04:16:41
的确，这也让我感到非常紧张。 – DavGarcia 2009-02-01 04:22:08
当您正在处理其他人以这种方式进行装饰的文件时，您是否删除了类似的东西？ – innaM 2009-02-01 09:59:19