Customizing SonarCloud rule sets

Posted by

We have been using SonarCloud for a few weeks now. We have a decent overview of what our code looks like, but we have also been finding a few false negatives. Below we can see our current summary, which shows most items are resolved. The code coverage is around 90%, and their are three “code smells”, many of which we feel are false negatives.

For example, the pull request shows some “code smells” we feel are overly aggressive. We prefer to explicitly show a condition like this, rather than using the “!condition” format, and we would like to relax this rule somewhat.

Creating a customer quality profile

Do achieve this, in our SonarCloud instance, we browse to the “quality profiles”, and observe the current profile, “Sonar way”, which is not editable. To edit, we need to copy the existing profile and name a new profile, “Sonar way (Relaxed)”.

In the new profile, we set it as the new default profile.

We then browse to the rules, find the one we don’t like, in this case, “Boolean literals should not be redundant”, and deactivate it.

Editing Quality gates

We are also having some trouble with code coverage. The current rule demands at least 80% code coverage on new code. We’ve found we regularly fails quality gates. We are happy with our overall code coverage (it’s ~90%), so we are going to change the rule to focus on overall code coverage instead of “new code” code coverage. In the account quality gates section, (not the projects quality gate section), select the “Sonar way” quality gate and copy it.

We are going to call this new quality gate: “Sonar way (Relaxed quality gate)”

We are then going to delete the code coverage rule we don’t like.

Then add a new rule, this one will be overall code coverage, set to 90%

Finally, we set this new quality gate as the default.

Resolving false positive “code smells”

On the front overview page, we also mentioned there were a few unresolved “code smells”. These are items that SonarCloud has detected *may* become a problem, and recommends we address them. In this case, they are relatively minor, as they are some commented interface features we have not yet developed. We have the choice to close these as “fixed”, “false positive”, or “won’t fix”. We are going to leave these for now, but these reminders are nice.

We are also generating a number of false positive hits on code we didn’t write. Finally, in “Administration”, “General settings”, we specify a few folders to ignore from code coverage, such as the bootstrap and JavaScript library folder, “/wwwroot/lib/“. We didn’t write these libraries, we aren’t planning to edit them, and as such, it is not fair that they are creating false positive bugs.

Wrap up

Some fairly project specific tweaks, but they advance our goals of helping to ensure we are confident that any development we do passes a number of tests and rules, increasing our confidence that our code going to production is of a high quality.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s