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
`@Suppressand Java’s@SuppressWarningsannotations- 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:
- Clone the Github repo:
git clone https://github.com/arturbosch/sonar-kotlin - Build the plugin
mvn package - 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:sonarI ran the analysis on the Kaadin project:
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.