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.

1 Like

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.


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.


Which is kind of the issue we have we code suppressions : what happens when the issue is fixed, how to get rid of code suppression ? is the code suppression hiding only one issue ?

What happens when the issue is fixed, how to get rid of code suppression?

Worst case, if you forget to remove the suppress annotation, you have a useless annotation in your code. This itself may be a code smell. Perhaps you can create a rule for this? :smile: “Rule XYZ suppressed here but no XYZ rule violation found” . Anyway, I think this is less of a problem than managing multiple sources of truth and having false positives pop up again when code is refactored.

is the code suppression hiding only one issue ?

This is exactly the point of this post. The // NOSONAR comment ignores all rules between a couple of lines. This post is requesting a feature to suppress a specific rule. So, if this feature is implemented, yes, the code suppression will be hiding only one issue.


@Lena have you made a decision yet?

1 Like

Nope, we are still discussing this topic. I will post update here when we will have something ready.
Thanks for the interest!

We also have hit this issue. Our use case is with our parametrized unit tests. The parameters are provided by a method which appears as unused. It’ll be great to use @Suppress("kotlin:S1144") as we don’t want to manually manage each in the UI

Our current solution is far from elegant, mostly due to readability and the fact that NOSONAR may block other issues:

@Suppress("unused") // Function is never used (intellij).
private fun testMethodParams(): Any { //NOSONAR - Unused function.
    return arrayOf(
        "1", "2", "3"

What we would like:

@Suppress("unused", "kotlin:S1144") // Function is never used.
private fun testMethodParams(): Any {
    return arrayOf(
        "1", "2", "3"
1 Like

I’ve also run into this issue now. I’ve used SonarLint for years with Java and it’s almost a deal-breaker to not have this working correctly in Kotlin as it introduces cognitive overhead to figure out which warnings are understood + tackled vs new ones that haven’t been (or are new).

I’ve already upvoted on the topic, but this seems like a baseline requirement for code analysis.

1 Like

This indeed is a dealbreaker for our company too.

We have stopped using sonar, fairly shortly after switching to Kotlin.
If tools can’t keep up with the development stack, those tools can only be marked as outdated.


Any update on this?

Using the UI to track the status of issues makes sense and is great for existing code.

However I feel that it doesn’t work well when writing new code and using SonarLint to pro-actively ensure quality. In such workflow it feels better to suppress issues as soon as SonarLint finds them rather than waiting for the code to be pushed and analysed by sonarqube. If you prefer to store the issue status in “sonar land” rather than in code then I think that SonarLint/SonarQube should offer a way to ignore an issue on code that is not yet known/analysed by SonarQube.

I’ve got a good news: SONARSLANG-491 was just fixed. It means it will be possible with SonarQube 8.6 and soon on SonarCloud to suppress issues for Kotlin and Scala using annotations.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.