Question

我正在尝试找到一个更好的替代默认的java质量配置文件“使用Findbugs的声纳方式”。

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

例如：

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

由于我找不到任何比默认规则更好的现成规则，我希望从经验丰富的Sonar用户那里获得有关此主题的反馈。

Answer 1

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

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

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

您可以使用“SonarQube Way with Findbugs”配置文件完全相同（但我不会这样做，因为这会启用大量规则......）

请记住，最好减少可以解释的规则，并且所有开发人员都愿意申请，而不是有很多难以解释的检查，没有人相信，没有人想要申请，也不会再读SQ了到了大量的支票。换句话说，从小开始，与你的开发者一起成长。

还要记住，没有修复的问题（没有人因为他的规则引起过多的误报，很难理解等而无法修复）是一种难以摆脱的债务。这种泄漏总会带来更多债务，主要是因为人们还没有准备好听到这些问题。在这种情况下，最好停用这些规则，并在人们准备好谈论它们并应用它们之后将它们带回来。

最后但并非最不重要。与开发团队就质量配置文件发布日期达成一致。让我们说，例如，您同意每年将有两个配置文件更新。在两个配置文件发布之间，欢迎人们讨论规则，但是如果需要修改（添加/删除规则），则不会在下一个版本之前修改这些规则，必须对其进行讨论并找到共识。如果项目在两个版本之间启动，则从当前配置文件开始并使用它。更新配置文件时，您的项目可能有一个版本将其代码与新规则对齐，或者如果您使用“修复泄漏”方法，项目会同意新代码和重构代码将遵循新配置文件。< / p>

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

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

Answer 2

是＆＃34;死存储到本地变量＆＃34;真的是一个关键问题？

这可能是一个严重的问题，因为它不仅仅表明在某些情况下浪费了内存。通常，此问题是由缺少或错误的变量访问引起的。考虑这个例子，其中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;
   }
}

使用等于比较字符串

可能规则＆＃34;对象应该与＆＃39; equals（）＆＃39;＆＃34;相反，它是活动的，并且隐含地涵盖了这个问题。

声纳：更好的java项目规则

2 个答案: