code quality

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 compare

This is the 3rd post in a series about creating a SonarQube plugin for the Kotlin language: The first post was about creating the parsing code itself.The 2nd post detailed how to use the parsing code to check for two rules. In this final post, we will be creating the plugin proper using the code of the 2 previous posts. The Sonar model The Sonar model is based on the following abstractions: Plugin Entry-point for plugins to inject extensions into SonarQube A plugin points to the ot

Last week, we used ANTLR to generate a library to be able to analyze Kotlin code. It’s time to use the generated API to check for specific patterns. API overview Let’s start by having a look at the generated API: KotlinLexer: Executes lexical analysis.KotlinParser: Wraps classes representing all Kotlin tokens, and handles parsing errors.KotlinParserVisitor: Contract for implementing the Visitor pattern on Kotlin code. KotlinParserBaseVisitor is its empty implementation, to ease t

Since I started my journey into Kotlin, I wanted to use the same libraries and tools I use in Java. For libraries - Spring Boot, Mockito, etc., it’s straightforward as Kotlin is 100% interoperable with Java. For tools, well, it depends. For example, Jenkins works flawlessly, while SonarQube lacks a dedicated plugin. The SonarSource team has limited resources: Kotlin, though on the rise - and even more so since Google I/O 17, is not in their pipe. This post series is about creating such a pl

15 years ago, automated tests didn’t exist in the Java ecosystem. One had to build the application and painfully test it manually by using it. I was later introduced to the practice of adding a main method to every class and putting some testing code there. That was only marginally better, as it still required to manually run the methods. Then came JUnit, the reference unit testing framework in Java which brought test execution automation. At that point, I had to convince teams I was part o