修改现有代码时使用了哪些特殊技术？
例如：假设您在方法中修改了业务规则。您是否用特殊注释标记修改的部分？
您在修改代码时使用的任何编码/注释标准？
SecretWiz
问问题
374 次
10 回答
14
你的意思是这样的：
foo(); // changed by SecretWiz, 20090131
我不会推荐这个。它使代码文件混乱，版本控制系统应该为您处理。它会跟踪谁更改了什么。采用
svn blame
于 2009-02-01T04:16:07.630 回答
4
如果我做一些诸如修复一个相对晦涩的错误之类的事情，基本上是任何不太明显为什么我以我的方式编写代码的事情，我通常会添加注释来解释它，以便我（或其他人，如果其他人曾经修改过我的代码 ;-) 以后不会意外删除它。
于 2009-02-01T07:27:53.047 回答
3
我总是尝试做的一件事是在我为该更改所做的代码签入注释中的错误跟踪系统中输入错误 ID（或功能请求 ID）。我添加了类似“有关更多详细信息，请参阅 bugzilla 中此错误/功能的评论”之类的内容。在那里，我可以并且通常可以解释该代码更改的基本原理。这意味着所有更改或至少所有重要更改都需要通过功能请求/错误 ID 进行跟踪。我多次创建错误只是为了详细解释所涉及的业务原因。
于 2009-02-01T07:34:55.763 回答
2
不，这真是个坏主意。您的源代码管理会保留所有编辑的历史记录。如果您想要其他东西，请在您的错误跟踪工具中输入。无需注释掉旧代码部分或在其中乱扔以下内容：
// modified by A.B. on 11/23/99 to fix issue #123456
我在我们的代码库中看到过这样的评论，而且这些评论多年后毫无意义。AB到底是谁，问题#123456是什么？如果代码仍然存在，这是否意味着有人计划在未来回滚这些更改？
这些注释没有任何价值，只会使您的代码混乱。
于 2009-02-01T04:16:23.370 回答
1
我建议创建一个方法并从正在修改的代码中调用它。
此外，命名方法以暗示方法的目的/意图。
例如
GiveRebateIfValidCoupon();
于 2009-02-01T04:18:35.113 回答
0
“您在修改代码时使用的任何编码/注释标准？”
是的。创建新的子类。保留旧代码，除非在极少数情况下您没有正确测试它并且实际上是错误的。
对需求的更改意味着添加子类和新测试来处理新的业务规则。
于 2009-02-01T04:21:48.260 回答
0
我添加特殊注释的唯一一次是修改是否是临时的。在那种情况下，我用一个标准关键字（例如，TEMPFIX）标记它，以便我以后可以找到它。当然，您必须记住返回并删除代码或进行永久性更改，但在某些项目中，我们已经强制使用允许我们指定代码停止编译的到期日期的宏。
除此之外，我们依赖源代码控制。
于 2009-02-01T04:35:21.867 回答
0
代码应符合您或您的组织拥有的任何编码标准。
所以，不，不应该有任何特殊的注释说明代码已被修改——所有或至少大部分代码迟早会被修改。
如果您继承的代码不符合注释标准，那么一定要在重构代码时添加注释。如果代码真的很旧并且没有文档，那自然意味着添加文档。
在修改代码之前理解代码是件好事（顺便说一句）。
于 2009-02-01T04:48:43.603 回答
0
通常我只会更改代码并在我的源代码管理检查中发表评论。在选择的任务跟踪工具中，您可以参考实现任务的修订版。
有时我知道某些功能会来回更改、移动、更改名称等，具体取决于用户需求的辩论方式。在这种特殊情况下，我会将旧版本保留在那里，然后将其注释掉。然后，稍后取消注释就变得微不足道了，而不是通过源代码控制寻找旧版本。如果他们以后必须维护您的代码，这也可以节省某人的屁股，因为当用户再次改变主意时，该要求已经在代码中，等待取消注释。
于 2009-02-01T05:04:00.670 回答
0
我必须同意这里的许多其他人的观点。“如果您的代码中不需要某些内容，请将其删除”。尤其是在生产代码中，您最不想要的就是很多混乱。与阅读您的维护评论并可能会感到困惑相比，有人可能更容易弄清楚您的更改是如何工作的。
我曾经在我的项目中保留旧的弃用代码，但随着时间的推移，一个应该只有几千行的项目最终超过了 10,000 行并且难以管理。
于 2009-02-01T07:10:21.490 回答