Support `@Suppress` for the sonarqube kotlin analyzer

The sonarqube kotlin analyzer currently doesn’t support any mechanism to suppress false positive issues in code.

An issue was opened to support suppression with //NOSONAR comments.

This is a nice first step, but is quite limited, as it doesn’t allow you to indicate which issue you’re suppressing. Furthermore, even if you only want to suppress one particular issue, all issues in the concerned lines will be suppressed, which means you may end up missing some real issues.

Java has @SuppressWarnings and detekt supports @Suppress to suppress specific rules.

It would be nice to have a similar mechanism for the kotlin sonar plugin.

Suggested example: @Suppress("kotlin:S107")

Hi @calvarez-ov,

At first let me thank you for coming here and providing this request. Indeed I understand the need, still I’m afraid that we will not implement it any time soon for multiple reasons. We are not big fans of in code exclusions, and even if we have NOSONAR we don’t promote it to users. The recommended way to ignore some issue is to mark it won't fix in SonarQube UI. Note this way is super precise, only this issue will be ignored, and if you have another issue on that line which should not be ignored you will still see it. Also work on Kotlin analyzer is not at high priority now, it’s unlikely we will invest a lot into it.

P.S. These is already a ticket to support @Suppress("UNUSED_PARAMETER") for S1172, but note it’s specific to one rule, it’s not a generic exclusion you are talking about

Hi @Lena,

Please do reconsider. Using the UI is indeed one option, but is limited. All the other static analyzers support this (findbugs, checkstyle, pmd). Being able to suppress in code means once source of truth, and less work when running against a new sonar instance – no migration or additional manual work required to resuppress those false positives.

I know some developers are staying on detekt, instead of migrating to the sonar kotlin plugin, specifically for this issue.

Thanks for your consideration.

Ok, we will discuss this topic in the team, and come back to you

1 Like

Hi @Lena
I agree with @calvarez-ov that code exclusions is something that is not only a nice to have, but can be a deal breaker. UI suppressions have some limitations, especially in SQ Community Edition. That’s why my team use code suppressions in Java and we also expect such feature from Kotlin plugin. We have started using your plugin with an assumption that this is only a temporary limitation and it will be “fixed” in near future. I know that there were no statements from your team that such feature will be ever delivered, but for us it was quite obvious that there’s a need for such functionality, especially when we noticed first steps towards delivering it, like mentioned ticked

If your team will decide that you can’t deliver such feature in reasonable amount of time, then some developers like my team might indeed migrate to one of 3rd party plugins that already supports this.

Please do reconsider your decision.

1 Like

Hi @robertszuba,

Can you please specify what are the limitations which you see?
I think that would help to understand the problem more deeply.

UI suppressions tends to come back. It happens a lot if you refactor code (i.e. extract code snippets to new classes or transform Java file into Kotlin file) or if you run analysis on something else than Master’s HEAD (in SQ CE).

With code suppressions we are able to mark false positives permanently.

1 Like