Why are so many rules inactive by default?

Must-share information (formatted with Markdown):

  • SonarQube
  • Determine why so many rules are inactive
  • Reviewed the default enabled rules in the default quality profiles

For example, the Sonar way / Python profile has 396 rules inactive by default. Seems a lot and a waste of rules. Why would they be inactive by default? Do they provide bad results if they are active?

Too many rules can generate a huge amount of issues and may lower the team’s morale.

I though this question was interesting, so with the help of @Nicolas_Harraudeau, we tried to go more in depth. Here is the output:

Python is a specific case. It was designed at first as an extension of Pylint. It provides some of its own rules (see here), and it also enables users to activate pylint rules in their quality profile. Pylint rules are however disabled by default and there are quite a few of them. As you have seen this behavior is a little confusing and we want to improve it.

Regarding disabled rules in general, I would suggest you to have a look at the quality profile overview.

Built-in Quality Profile (the Sonar way ) […] are designed by SonarSource with rules that are generally applicable for most projects.

The Sonar way Quality Profiles are a good starting-point as you begin analyzing code, and they start out as the default Quality Profiles for each language. That being said, we recommend that you Copy this profile and begin to fine-tune the contents.

As @edu answered, it makes sense to avoid flooding a new user with too many issues the first time he runs an analysis, and let him go deeper (enable more rules) when he feels comfortable with the tool.

However this is not the only reason why some rules are disabled by default:

1/ When a rule is deprecated, it is removed from default profile before being completely removed. This is just to be backward compatible, i.e. not change drastically the quality profiles every time a plugin is updated. We deprecate rules when:

  • we find a better one.
  • a rule raises too many false positives and there is no way to improve it. This rarely happens as we use our own products at SonarSource, but it happens from time to time.
  • we merge rules together. This is a kind of refactoring which also happens from time to time.

2/ Some rules are controversial. The most obvious ones are related to code style. Such rules can easily contradict themselves.

3/ Sometimes, a rule is only valid in specific contexts, i.e. it depends on the kind of project (Website, CLI, etc…), or the technology used (Java version, JUnit, …). For example S1082 might not make sense for all websites.

Do they provide bad results if they are active?

Except for deprecated rules, No. Disabled rules can provide good results, but not for every project. Rules which are enabled by default are the ones we believe will work for every project.

Hope this answers your question!