我正在尝试找到一个更好的替代默认 java 质量配置文件“Sonar way with Findbugs”的方法。
在配置文件的516条规则中，有些规则实际上没有设置正确(优先级或激活)。
例如:
- “局部变量的死存储”真的是一个关键问题吗？
- “添加空字符串”已禁用，但值得启用。
- “使用等于比较字符串”被禁用...
因为我找不到比默认规则更好的现成规则集，所以我想从有经验的 Sonar 用户那里获得关于这个主题的反馈。
最佳答案
我的经验(自 SQ 在 3 家不同的公司首次发布以来我一直在使用，这些年来编写了 130 多项自定义检查)如下:
- 创建一个配置文件 P1，它是当前“SonarQube Way”配置文件的副本
- 在此配置文件中删除与您的上下文无关的所有规则(主要是如果您有与现成规则冲突的自定义规则)并在需要时更改优先级(仅在您的上下文需要时才尝试增加优先级。)跟踪修改配置文件的原因。这里的重点是能够说“我们遵循现成的配置，除了一些我们想要更严格控制的特定情况”。此配置文件将用于轻松地将您当前的“SonarQube Way”配置文件与更新的配置文件进行比较。
- 创建一个配置文件 P2，它继承自 P1 并添加其他规则，无论是否自定义。与您的开发团队一起研究这个主题，以达成共识。
- 尽可能保持您添加的规则的默认优先级(不要给那些想要争论您的配置有缺陷的人提供食物，如果您需要更改优先级，请准备好捍卫您的决定，请参阅下一步点。)
- 对于所有规则优先级更改(现成的和/或自定义规则)，请遵循预定义的比例(例如 this one)并坚持下去。
- 将 P2 设置为默认配置文件。
然后每次“SonarQube Way”进化你都可以轻松更新它，然后将它与 P1 进行比较。
您可以使用“SonarQube Way with Findbugs”配置文件做完全相同的事情(但我不会这样做，因为这会启用很多规则...)
永远记住，最好有更少的规则你可以解释并且所有开发人员都愿意申请而不是有很多难以解释的检查，没有人相信也没有人愿意申请，也不再阅读 SQ 由于到巨额支票。换句话说，从小处着手，然后与您的开发者同行一起成长。
还要记住， Unresolved 问题(由于他的规则会引起太多误报，难以理解等，因此没有人愿意解决)是难以摆脱的债务。这是一个总是会带来更多债务的泄漏，主要是因为人们还没有准备好听到这些问题。在这种情况下，最好先停用这些规则，然后在人们准备好谈论并应用它们时再将它们带回来。
最后但并非最不重要的一点。与开发团队就质量配置文件发布日期达成一致。比方说，您同意每年更新两次个人资料这一事实。在两个配置文件发布之间，欢迎人们讨论规则，但这些规则要等到下一个版本才能修改，如果需要修改(添加/删除规则)，则必须进行讨论并达成共识。如果一个项目在两个版本之间开始，它会从当前配置文件开始并使用它。当配置文件更新时，您的项目可能会有一个版本以使其代码与新规则保持一致，或者如果您使用“修复泄漏”方法，项目同意新代码和重构代码将遵循新配置文件。
请记住，如果您是配置文件的所有者，您的开发人员应该是要求添加新规则的人(顺便说一句，这是一个很好的 KPI。)
关于这个还有很多要说的，但这应该是一个很好的起点，以便为您提供帮助。
关于java - Sonar : better rules for java projects，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12798108/