对评论进行编程

Question

多年来，我发现绿色程序员倾向于阅读注释而不是代码来调试问题。

让一个人记录另一个人的代码（反之亦然），代码编写者的批准可以长期提高代码质量吗？

这是个好主意吗？

抛开：我正在寻找预算编制和结对编程之间的中间立场。

Answer 1

人们倾向于寻找解决问题的最简单方法。如果有可用的“人类”描述，则可能在读者深入研究深奥代码之前使用它。 IOW，通常会首先考虑注释，无论程序员是多么绿色。

评论应尽可能保持。不幸的是，它们很容易变得陈旧（因为编译器无法验证它们）。因此，它们应该保持在合理的最小值，因为最终，代码本身是唯一可以信任的真实注释。

至于谁应该写评论，这取决于评论的写入级别。例如，在更高级别，注释应该描述模块的外部行为，并且可以由更多人编写。但是，在内部，注释应该解释各种代码块的意图。这样，读者就可以更容易地收集代码的习惯。这些评论应该由编码员编写。

Answer 2

我发现当一个人编写代码而另一个人编写单元测试时，“结对编程”效果最好（并排工作，这样他们就能看到对方在做什么）。您也可以偶尔交换角色。

Answer 3

如果原作者没有记录代码，那么你会冒错误解释算法的风险。在我看来，唯一比令人费解的代码更令人沮丧的是代码编写错误。

您可能希望尝试这种方法：

• 与未参与编程工作的开发人员进行代码审查。
• 在没有代码作者实际存在的情况下执行审核。只是审阅者，源代码控制代码的副本和书面文档。
• 如果审稿人在没有外界协助的情况下无法合理地理解代码，则没有充分记录，应该回复给作者。
• 根据需要重复。

Answer 4

我倾向于先写评论，然后立即编写评论，或者有时或者有时并排编码。当我最终写出我的评论时，代码在我的脑海中变得非常清晰（而不是在撰写评论时用语言表达我的想法）。我不想评论我没写的代码。每当我回来修改代码时，首先阅读原始注释，然后考虑新注释，编写它们并将代码并排编写。

Answer 5

我发现当帮助者进行广泛的思考（即我们想要完成什么）并且键盘牛仔做详细范围思考时，它最有效。我不认为评论与它有任何关系。