FAQ - QualInsight/qualinsight-plugins-sonarqube-smell GitHub Wiki

Plugin name

Why is the plugin called "Code Smells" ?

This name was chosen as a reference to Martin Fowler's blog article.

Isn't "Code Smells" a first class citizen of the SonarQube Quality Model ?

Yes it is.

However, it is Martin Fowler who democratised the Code Smell term and defined it as a surface indication that usually corresponds to a deeper problem in the system in his Code Smell blog post written the 9th of February 2006. The "Code Smells Plugin" has this name since version 2.0.0, i.e. since the 22nd of October 2015. SonarSource started using the Code Smell term when they released the SonarQube quality model in June 2016 as a part of SonarQube 5.5. Until then they were using the SQALE quality model which does not make any reference to Code Smells.

In other words SonarQube started using the "Code Smell" term in its Quality Model around 8 months after I released the plugin under the name "Code Smells Plugin" and almost 10 years and a half after Martin Fowler wrote his blog post.

IMHO, SonarQube is misusing the Code Smell term as multiple rules are clearly not a surface indication of a deeper problem in the system (see for instance squid:CallToDeprecatedMethod, and all the rules tagged as convention)

Supported languages

What are currently supported languages by the plugin?

Currently, only Java is supported.

Do you plan to add support for languages other than Java (for instance JavaScript, C#, COBOL, etc.) ?

I would like to. However this means that the architecture of the plugin will have to be modified. Indeed, the plugin is currently tightly bound to the sonar-java plugin, it should be split in order to have a generic language agnostic part and extensions for different languages.

Needless to say that I will work on this only if there is enough interest in such a feature. So if you're interested, or if you want to help and contribute in any way. Please contact me!

Plugin behaviour

I added @Smellannotations to my code then analysed my project, however no new issues (or only some issues) are displayed in SonarQube. Why ?

In order to have Code Smells issues created each time a @Smell annotation is detected, you have to add all checks part of the Smells repository to the quality profile used to analyse your project's code.

Comparison with other tools

How does the Code Smells plugin compare with tools such as Gerrit?

Gerrit is a great tool for integrating code reviews in your software lifecycle development. I definitively recommend using it.

With Gerrit, when a developer commits code, in fact he uploads it to Gerrit. There, the code is in "purgatory" waiting for a manual code review that will decide if the code's quality is good enough. Through a web user interface, Gerrit allows to ask questions, report issues and code smells, discuss them, and force developers to fix them before allowing Gerrit to effectively commit the code to your SCM.

But what happens if the code is already in your SCM and you want to review it? Gerrit does not support this kind of use case as the code has already been committed. Further, Gerrit does not keep any notion of required effort to fix a finding.

The Code Smells plugin allows you to review code, evaluate related technical debt and commit the results of your review to the SCM. If you're using Gerrit, review's findings can be discussed before being committed to the SCM. Then reported code smells appear in SonarQube waiting for user actions and future refactoring. Scrum Masters, Project Managers, Architects and Developers can see in SonarQube reported code smells and related technical debt.

Therefor, Code Smells plugin for SonarQube is complementary to Gerrit.