vec*_*tor 8 java code-comments sonarqube
在我的一个项目上运行Sonar后,我发现了"尾随评论"的违规行为.所以我想知道,这是否与Java的接受/推荐的代码布局约定完全相关,还是"它还有更多"？背后的原因是什么？当我查看一些C++代码时(最近的Doom代码审查,有大量(或充满活页夹)的尾随注释.
Swa*_*nil 15
来自着名的书Code Complete:
必须对齐注释,以便它们不会干扰代码的可视结构.如果你没有整齐地对齐它们,它们会使你的列表看起来像是通过洗衣机.
结束语评论往往难以格式化.对齐它们需要时间.没有花时间学习更多关于代码的知识; 它专门用于按空格键或标签键的繁琐任务.
终结评论也难以维持.如果包含结束注释的任何行上的代码增长,则会使注释更加突出,并且所有其他结束注释都必须突然匹配.不保持难以维护的样式.
终结评论也往往是神秘的.该行的右侧不提供太多空间,并且希望将评论保持在一行意味着评论必须很短.然后工作尽可能地缩短生产线,而不是尽可能清晰.评论通常最终会变得神秘.
终结评论的一个系统性问题是,很难为一行代码编写有意义的评论.大多数结束语评论只是重复代码行,这会比它有所帮助.
话虽如此,它也是关于编码风格的选择.我个人会避免尾随评论,因为他们没有那么多帮助.
仅仅因为某些内容有落后的评论并不意味着它们是好的.另外请记住,Doom 3的代码大约有10年的历史,编码风格随着时间的推移而变化.
通常,尾随注释表明一行代码不能独立存在.而且,一般来说,这是代码味道,因为单行代码应该相当透明.
通过查看一些源代码,我实际上看不到大量的尾随注释,但是我看到很多方法太长了,并且在函数中间有很多注释.
这些通常表明以下代码值得拥有自己的方法.
我认为是的,还有更多,而"更多"是沟通和清晰.