示例1

规则： BadConstantName_S00115_Check / S00115

我们所有的枚举都是使用camelCase而不是CONSTANT_NAME实现的，例如：

public enum Classification {
    PoorMinus(1),
    Poor(2),
    PoorPlus(3),
    OrdinaryMinus(4),
    Ordinary(5),

比以下更容易阅读：

public enum Classification {
    POOR_MINUS(1),
    POOR(2),
    POOR_PLUS(3),

这样做是为了提高代码中其他地方引用的可读性（使用静态导入）

所以我正在寻找的是一种抑制枚举这个规则的方法，因为我们希望保持＆＃34;真实＆＃34;常数。

示例2

规则： MethodCyclomaticComplexity

迁移此规则后，报告所有equals和hashcode方法的复杂性。（对于这些方法，已弃用的CS规则很容易被抑制）

测量Eclipse / IntelliJ自动生成的方法的复杂性是没有意义的（至少对我们而言）。重要的是衡量＆＃34;业务逻辑的复杂性。部分代码

在这里，我们真的想要取消这些/特定方法的规则

规则：UndocumentedApi

我想确保仅在类级别（而不是方法/字段）的接口（包括类和方法）和类的javadoc。就像现在一样，这是不可能的。同样，我想禁用检查方法和字段

有人知道如何实现这种抑制吗？我查看了SonarQube上的设置/排除，但是使用排除设置实现这一点似乎非常困难甚至不可能。

所以我们真正需要的是能够调整规则来抑制某些类型和方法的检查，使规则更加灵活。理想情况下，这应该作为一般功能实现，可以很容易地应用于有意义的规则。

至于现在我必须禁用这些规则（并且很可能也禁用其他规则），因为规则的配置不是细粒度的。

我可以在哪里提交此功能请求？

我已经从Github检查了源代码，因此目前正在寻找以编程方式修复这些问题。然而，这不是一个可行的长期解决方案。

Answer 1

Dag是正确的，这些规则没有配置。在SonarSource进行内部讨论之后，不会添加配置文件。

根据所讨论的here

，最适合您的情况是使用Java实现自定义规则

Answer 2

我也看到了其他规则的类似需求，但我认为新哲学是别的：

配置选项太多：在完美的世界中，优质的规则是一条规则，没有任何配置选项。

PS：不知怎样，我对使用SonarQubes自己的规则引擎使PMD，Checkstyle和Findbugs过时的非常长期的野心感到不舒服，但这只是我的观点。

特别是PMD的方式并不长。 Support for PMD 5似乎没有出现，SonarQube 4.2默认情况下甚至没有pmd-plugin。