/ KOTLIN, CODE QUALITY, SONARQUBE

Check the quality of Kotlin code

Last week, I read a post about Kotlin code analysis, thanks to the Kyiv Kotlin UG. I stumble upon a lot of similar posts: they show how to hack into the build to produce a text report showing quality issues.

At the risk of sounding arrogant, I claim this is not proper software engineering. It’s a one-time hack: it has no value over the long term. Code quality is a serious subject, and should be treated accordingly. First, it needs to be evaluated, then issues have to be stored and compared during the entire lifetime of the project. The good thing is that the tooling to achieve that is already available, and I hope is part of everyone’s build pipeline: it’s SonarQube.

Detekt

Detekt provides static code analysis for Kotlin.

I tried previously to kickstart an initiative to develop a SonarQube plugin for Kotlin. It didn’t catch on - and had other interests to pursue. That’s fine, Detekt does a much better job.

From Detekt’s Github page, features are:

  • code smell analysis for your kotlin projects
  • complexity report based on logical lines of code, McCabe complexity and amount of code smells
  • highly configurable (rule set or rule level)
  • suppress findings with Kotlin’s `@Suppress and Java’s @SuppressWarnings annotations
  • specify code smell thresholds to break your build or print a warning
  • code Smell baseline and ignore lists for legacy projects
  • extensible by own rule sets and FileProcessListener’s

In addition to all of that, it also provides a plugin to integrate into SonarQube, thus benefiting from the later storing and comparing capabilities.

Set up

SonarQube makes it easy to install new plugins: the embedded Marketplace capability lists all available published plugins. Just check the ones you want and you’re done!

Unfortunately, Detekt is not part of the marketplace yet.

There’s an open issue. Subscribe should you want to be informed about its progress.

Thus, setting up the plugin is a manual process:

  1. Clone the Github repo:
    git clone https://github.com/arturbosch/sonar-kotlin
  2. Build the plugin
    mvn package
  3. Copy the JAR to the SonarQube plugin folder (i.e. $SONAR_HOME/extensions/plugins)

Run the check

As usual, running the check is just a matter of the standard command-line:

mvn sonar:sonar

I ran the analysis on the Kaadin project:

Kaadin code analysis results

Of course, this is the raw analysis, with default rules. However, it already makes a lot of sense.

Conclusion

In the JVM ecosystem, a lot of tooling is already available - for free. Most (if not all) Java projects I know of have build pipelines in place since ages: they check out the code, compile it, run tests, perform quality checks, etc. Why should those pipelines be discarded by switching to Kotlin? Detekt makes it easy to reuse one’s continuous integration build chains by just providing the missing component.

Nicolas Fränkel

Nicolas Fränkel

Nicolas Fränkel is a Software Architect with 15 years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with narrower interests like Software Quality, Build Processes and Rich Internet Applications. Currently working for an eCommerce solution vendor leader. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.

Read More