Sonarqube: Squid Rules customization/suppression

Question

I have spent a day migrating all PMD and Checkstyle rules to the new Squid rules, as the PMD/Checkstyle ones are marked as deprecated.

However, some fine tuning options which I am used to with PMD/CS, are not present in Squid.

As a result, Sonar is cluttered with thousands of issues which reports nothing of real value.

Example 1

Rule: BadConstantName_S00115_Check / S00115

All our enums are implemented with camelCase instead of CONSTANT_NAME, e.g.:

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

is easier to read than:

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

This is done to improve readability when referenced elsewhere in the code (using static imports)

So what I am looking for is a way to suppress this rule for enums, as we want to keep the rule for "real" constants.

Example 2

Rule: MethodCyclomaticComplexity

After migrating this rule reports complexity for all equals and hashcode methods. (the deprecated CS rule was easy to suppress for these methods)

It makes no sense (at least for us) to measure complexity of methods which are auto-generated by Eclipse/IntelliJ. What is important is to measure complexity on the "business logic" part of the code

Here we would really like to suppress the rule for these/specific methods

Example 3

Rule: UndocumentedApi

I want to ensure javadoc for interfaces (including class and methods) and classes at class level only (not methods/fields). As it is now, this is not possible. Again, I would like to disable checking for methods and fields

CHALLENGE

Does anybody know how to achieve these kind of suppression? I have looked at Settings / Exclusions on SonarQube, however it seems very hard or even impossible to achieve this with the exclusions settings.

So what we really need is to be able to tweak rules to suppress checking of certain types and methods, to make the rules more flexible. Ideally this should be implemented as a general features, which can be easily applied to rules where this makes sense.

As for now I have to disable these rules (and most likely others as well), because the configuration of the rules are not fine-grained.

Where can I submit this as a feature request?

I have checked out the source from Github, so currently looking into programmatically fixing these issues. This is however not a viable long-term solution.

Answer 1

Dag is correct, these rules have no configurations. After internal discussions at SonarSource, configuratons are not going to be added.

The best idea for your situation would be to implement custom rules in Java as discussed here

Answer 2

I have seen similar need on other rules too, but i guess the new philosophy is something else:

http://www.sonarqube.org/already-158-checkstyle-and-pmd-rules-deprecated-by-sonarqube-java-rules/

Too many configuration options: in a perfect world, a good quality rule is a rule WITHOUT any configuration options.

PS: Somehow i don't feel comfortable with the very long term ambition of making PMD, Checkstyle and Findbugs obsolete via SonarQubes own rule engine, but this is just my opinion.

Especially for PMD the way isn't that long. Support for PMD 5 doesn't seem to come and SonarQube 4.2 does not even have the pmd-plugin by default.