在我的某个项目上运行Sonar后，我发现了“尾随评论”的违规行为。所以我想知道，这是否与Java的接受/推荐的代码布局约定完全相关，还是“它还有更多”？背后的原因是什么？当我查看一些C ++代码（最近的Doom code review时，有大量（或充满了粘合剂）的尾随注释。
答案 0 :(得分：15)
来自着名的书Code Complete：
必须对齐注释，以便它们不会干扰代码的可视结构。如果你没有整齐地对齐它们，它们会使你的清单看起来像是通过洗衣机。
Endline评论往往难以格式化。对齐它们需要时间。没有花时间学习更多关于代码的知识;它专门用于按空格键或标签键的繁琐任务。
结束语评论也很难维护。如果包含结束注释的任何行上的代码增长，则会使注释更加突出，并且所有其他结束注释都必须突然匹配。不能维护难以维护的样式。
终结评论也往往含糊不清。该行的右侧不提供太多空间，并且希望将评论保持在一行意味着评论必须很短。然后工作尽可能地缩短生产线，而不是尽可能清晰。评论通常最终会变得神秘。
结束语注释的系统性问题是，很难为一行代码编写有意义的注释。大多数结束语评论只是重复代码行，这会比帮助更多。
话虽如此，它也是关于编码风格的选择。我个人会避免尾随评论，因为他们没有帮助 。
答案 1 :(得分：5)
仅仅因为某些有尾随评论并不意味着他们好。另外请记住，Doom 3的代码大约有10年的历史，编码风格会随着时间而变化。
通常，尾随注释表明一行代码不能独立存在。而且，一般来说，这是代码味道，因为单行代码应相当透明。
查看一些来源我实际上并没有看到大量的尾随注释，虽然我看到很多方法太长，并且在函数中间有很多注释
这些通常表明以下代码值得拥有自己的方法。
我认为是的，还有更多，而“更多”是沟通和清晰。
答案 2 :(得分：4)
尾随评论本身并不是坏事。但是，您应该尽可能清楚地编写代码，这样您就不必使用注释逐行解释代码。这就是为什么有些人会将尾随代码注释视为代码不可理解的暗示。
有关详细信息，另请参阅Java Style Guide。