3

我试图找到一个更好的替代默认 java 质量配置文件“Sonar way with Findbugs”。

在配置文件的 516 条规则中，有一些实际上没有正确设置（优先级或激活）。

例如：

  • “死存储到局部变量”真的是一个关键问题吗？
  • “添加空字符串”已禁用，但值得启用。
  • “使用等于比较字符串”已禁用...

由于我找不到任何比默认规则更好的即用型规则集，我想从有经验的 Sonar 用户那里获得有关此主题的反馈。

4

2 回答 2

1

我的经验（自 SQ 在 3 家不同的公司首次发布以来，我一直在使用它，多年来编写了 130 多份自定义检查）如下：

  • 创建作为当前“SonarQube Way”配置文件副本的配置文件 P1
  • 在此配置文件中删除所有与您的上下文无关的规则（主要是如果您有一个与现成规则冲突的自定义规则）并在需要时更改优先级（仅在您的上下文需要时尝试增加优先级。） 跟踪修改配置文件的原因。这里的重点是能够说“我们遵循现成的配置，除了一些我们想要更严格控制的特定情况”。此配置文件将用于轻松地将您当前的“SonarQube Way”配置文件与较新的配置文件进行比较。
  • 创建一个从 P1 继承并添加其他规则的配置文件 P2，无论它们是否自定义。与您的开发团队一起讨论这个主题，以便达成共识。
  • 尽可能保留您添加的规则的默认优先级（不要给那些想要争论您的配置有缺陷的人提供食物，如果您需要更改优先级，请准备好捍卫您的决定，请参阅下一点。）
  • 对于所有规则优先级更改（现成和/或自定义规则），请遵循预定义的比例（例如这个）并坚持下去。
  • 将 P2 设为默认配置文件。

然后每次“SonarQube Way”进化时，您都可以轻松更新它，然后将其与 P1 进行比较。

您可以使用“SonarQube Way with Findbugs”配置文件执行完全相同的操作（但我不会这样做，因为这会启用很多规则......）

永远记住，你可以解释的规则越少越好，所有开发人员都愿意申请，而不是有很多难以解释的检查，没有人相信，没有人想申请，也因为巨大的 SQ 不再阅读支票金额。换句话说，从小处着手，与您的开发人员一起成长。

还请记住，未解决的问题（由于他的统治引发了太多误报、难以理解等事实，没有人愿意解决）是难以摆脱的债务。这是一个总是会带来更多债务的泄漏，主要是因为人们还没有准备好听到这些问题。在这种情况下，最好在人们准备好谈论它们并应用它们时停用这些规则并在以后将它们带回来。

最后但并非最不重要的。就质量配置文件的发布日期与开发团队达成一致。例如，假设您同意每年将有两次个人资料更新这一事实。在两个配置文件发布之间，欢迎人们讨论规则，但这些规则要到下一个版本才能修改，如果需要修改（添加/删除规则），必须讨论并达成共识。如果一个项目在两个版本之间开始，它会从当前配置文件开始并使用它。当配置文件更新时，您的项目可能有一个版本来使其代码与新规则保持一致，或者如果您使用“修复泄漏”方法，项目同意新代码以及重构代码将遵循新配置文件。

请记住，如果您是配置文件的所有者，您的开发人员应该是要求添加新规则的人（顺便说一下，这是一个很好的 KPI。）

关于这一点还有很多话要说，但这应该是一个很好的起点，以帮助您。

于 2015-11-24T14:05:26.773 回答
0

“死存储到局部变量”真的是一个关键问题吗？

这可能是一个严重的问题，因为它不仅仅表示在某些情况下浪费了内存。通常，此问题是由缺少或错误的变量访问引起的。考虑这个m_valueY将被标记为死存储的示例：

public class ResultData {
  private int m_valueX;
  private int m_valueY;

  public int getValueX() {
    return m_valueX;
   }
   public int getValueY() {
     //should actually be m_valueY
     return m_valueX;
   }
   public void setValueX(int valueX) {
     m_valueX = valueX;
   }
   public void setValueY(int valueY) {
     m_valueY = valueY;
   }
}

使用等于比较字符串

可能“对象应该与'equals（）'进行比较”规则是活跃的，并且隐含地涵盖了这个检测到的问题。

于 2015-03-06T08:45:43.857 回答