Posts Tagged ‘code quality’
  • A SonarQube plugin for Kotlin - Creating the plugin proper

    SonarQube Continuous Inspection logo

    :page-liquid: :experimental: :imagesdir: /assets/resources/sonarqube-plugin-kotlin/

    This is the 3^rd^ post in a serie about creating a SonarQube plugin for the Kotlin language:

    • The link:{% post_url 2017-06-11-kotlin-plugin-sonarqube-part-1 %}[first post^] was about creating the parsing code itself.
    • The link:{% post_url 2017-06-18-kotlin-plugin-sonarqube-part-2 %}[2^nd^ 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:: + [quote] Entry-point for plugins to inject extensions into SonarQube + A plugin points to the other abstraction instances to make the SonarQube platform load them + AbstractLanguage:: Pretty self-explanatory. Represents a language - Java, C#, Kotlin, etc. ProfileDefinition:: + [quote] Define a profile which is automatically registered during sonar startup + A profile is a mutable set of fully-configured rules. While not strictly necessary, having a Sonar profile pre-registered allows users to analyze their code without further configuration. Every language plugin offered by Sonar has at least one profile attached. + RulesDefinition:: + [quote] Defines some coding rules of the same repository + Defines an immutable set of rule definitions into a repository. While a rule definition defines available parameters, default severity, etc. the rule (from the profile) defines the exact value for parameters, a specific severity, etc. In short, the rule implements the role definition. + Sensor:: + [quote] A sensor is invoked once for each module of a project, starting from leaf modules. The sensor can parse a flat file, connect to a web server… Sensors are used to add measure and issues at file level. + The sensor is the entry-point where the magic happens.


    == Starting to code the plugin

    Every abstraction above needs a concrete subclass. Note that the API classes themselves are all fairly decoupled. It’s the role of the Plugin child class to bind them together.


    class KotlinPlugin : Plugin {

    override fun define(context: Context) {
    } } ----

    Most of the code is mainly boilerplate, but for ANTLR code.

    == Wiring the ANTLR parsing code

    On one hand, the parsing code is based on generated listeners. On the other hand, the sensor is the entry-point to the SonarQube parsing. There’s a need for a bridge between the 2.

    In the first article, we used an existing grammar for Kotlin to generate parsing code. SonarQube provides its own lexer/parser generating tool ([SonarSource Language Recognizer^]). A sizeable part of the plugin API is based on it. Describing the grammar is no small feat for any real-life language, so I preferred to design my own adapter code instead.

    AbstractKotlinParserListener:: Subclass of the generated ANTLR KotlinParserBaseListener. It has an attribute to store violations, and a method to add such a violation. Violation:: The violation only contains the line number, as the rest of the required information will be stored into a KotlinCheck instance. KotlinCheck:: Abstract class that wraps an AbstractKotlinParserListener. Defines what constitutes a violation. It handles the ANTLR boilerplate code itself.

    This can be represented as the following:


    == The sensor proper

    The general pseudo-code should look something akin to:


    FOR EACH source file FOR EACH rule Check for violation of the rule FOR EACH violation Call the SonarQube REST API to create a violation in the datastore —-

    This translates as:


    class KotlinSensor(private val fs: FileSystem) : Sensor {

    val sources: Iterable<InputFile>
        get() = fs.inputFiles(MAIN)
    override fun execute(context: SensorContext) {
        sources.forEach { inputFile: InputFile ->
            KotlinChecks.checks.forEach { check ->
                val violations = check.violations(inputFile.file())
                violations.forEach { (lineNumber) ->
                    with(context.newIssue().forRule(check.ruleKey())) {
                        val location = newLocation().apply {
    } } ----

    == Finally, the run

    Let’s create a dummy Maven project with 2 classes, Test1 and Test2 in one Test.kt file, with the same code as last week. Running mvn sonar:sonar yields the following output:

    image::sonarqube-screenshot.png[SonarQube screenshot,799,640,align=”center”]

    Et voilà, our first SonarQube plugin for Kotlin, checking for our custom-developed violations.

    Of course, it has (a lot of) room for improvements:

    • Rules need to be activated through the GUI - I couldn’t find how to do it programmatically
    • Adding new rules needs updates to the plugin. Rules in 3^rd^-party plugins are not added automatically, as could be the case for standard SonarQube plugins.
    • So far, code located outside of classes seems not to be parsed.
    • The walk through the parse tree is executed for every check. An obvious performance gain would be to walk only once and do every check from there.
    • A lof of the above improvements could be achieved by replacing ANTLR’s grammar with Sonar’s internal[SSLR^]
    • No tests…

    That still makes the project a nice starting point for a full-fledged Kotlin plugin. Pull requests are welcome!

    Categories: Technical Tags: code qualitySonarQubeKotlinpluginANTLR
  • A SonarQube plugin for Kotlin - Analyzing with ANTLR

    SonarQube Continuous Inspection logo

    :page-liquid: :experimental: :imagesdir: /assets/resources/sonarqube-plugin-kotlin/

    Last week, we used ANTLR to generate a library to be able to link:{% post_url 2017-06-11-kotlin-plugin-sonarqube-part-1 %}[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 the creation of subclasses.
    • KotlinParserListener: Contract for callback-related code when visiting Kotlin code, with KotlinParserBaseListener its empty implementation.


    Class diagrams are not the greatest diagrams to ease the writing of code. The following snippet is a very crude analysis implementation. I’ll be using Kotlin, but any JVM language interoperable with Java could be used:


    val stream = CharStreams.fromString(“fun main(args : Array) {}") <1> val lexer = KotlinLexer(stream) <2> val tokens = CommonTokenStream(lexer) <3> val parser = KotlinParser(tokens) <4> val context = parser.kotlinFile() <5> ParseTreeWalker().apply { <6> walk(object : KotlinParserBaseListener() { <7> override fun enterFunctionDeclaration(ctx: KotlinParser.FunctionDeclarationContext) { <8> println(ctx.SimpleName().text) <9> } }, context) } ----

    Here’s the explanation:

    <1> Create a CharStream to feed the lexer on the next line. The CharStreams offers plenty of static fromXXX() methods, each accepting a different type (String, InputStream, etc.) <2> Instantiate the lexer, with the stream <3> Instantiate a token stream over the lexer. The class provides streaming capabilities over the lexer. <4> Instantiate the parser, with the token stream <5> Define the entry point into the code. In that case, it’s a Kotlin file - and probably will be for the plugin. <6> Create the overall walker that will visit each node in turn <7> Start the visiting process by calling walk and passing the desired behavior as an object <8> Override the desired function. Here, it will be invoked every time a function node is entered <9> Do whatever is desired e.g. print the function name

    Obviously, lines 1 to 7 are just boilerplate to wire all components together. The behavior that need to be implemented should replace lines 8 and 9.

    == First simple check

    In Kotlin, if a function returns Unit - nothing, then explicitly declaring its return type is optional. It would be a great rule to check that there’s no such explicit return. The following snippets, both valid Kotlin code, are equivalent - one with an explicit return type and the other without:


    fun hello1(): Unit { println(“Hello”) }

    fun hello2() { println(“Hello”) } —-

    Let’s use grun to graphically display the parse tree (grun was explained in the link:{% post_url 2017-06-11-kotlin-plugin-sonarqube-part-1 %}[previous post^]). It yields the following:

    image::parse_tree_return_unit.png[“Parse tree returns Unit”,910,align=”center”]

    As can be seen, the snippet with an explicit return type has a type branch under functionDeclaration. This is confirmed by the snippet from the KotlinParser ANTLR grammar file:


    modifiers ‘fun’ typeParameters? (type ‘.’ | annotations)? SimpleName typeParameters? valueParameters (‘:’ type)? typeConstraints functionBody? SEMI* ; —-

    The rule should check that if such a return type exists, then it shouldn’t be Unit. Let’s update the above code with the desired effect:


    ParseTreeWalker().apply { walk(object : KotlinParserBaseListener() { override fun enterFunctionDeclaration(ctx: KotlinParser.FunctionDeclarationContext) { if (ctx.type().isNotEmpty()) { <1> val typeContext = ctx.type(0) <2> with(typeContext.typeDescriptor().userType().simpleUserType()) { <3> val typeName = this[0].SimpleName() if (typeName.symbol.text == “Unit”) { <4> println(“Found Unit as explicit return type “ + <5> “in function ${ctx.SimpleName()} at line ${typeName.symbol.line}”) } } } } }, context) } —-

    Here’s the explanation:

    <1> Check there’s an explicit return type, whatever it is <2> Strangely enough, the grammar allows for a multi-valued return type. Just take the first one. <3> Follow the parse tree up to the final type name - refer to the above parse tree screenshot for a graphical representation of the path. <4> Check that the return type is Unit <5> Prints a message in the console. In the next step, we will call the SonarQube API there.

    Running the above code correctly yields the following output:

    [source] Found Unit as explicit return type in function hello1 at line 1

    == A more advanced check

    In Kotlin, the following snippets are all equivalent:


    fun hello1(name: String): String { return “Hello $name” }

    fun hello2(name: String): String = “Hello $name”

    fun hello3(name: String) = “Hello $name”

    Note that in the last case, the return type can be inferred by the compiler and omitted by the developer. That would make a good check: in the case of a expression body, the return type should be omitted. The same technique as above can be used:

    . Display the parse tree from the snippet using grun:
    . Check for differences. Obviously:
    * Functions that do not have an explicit return type miss a type node in the functionDeclaration tree, as above
    * Functions with an expression body have a functionBody whose first child is = and whose second child is an expression
    . Refer to the initial grammar, to make sure all cases are covered.
    block | ‘=’ expression ; —- + . Code! + [source,java] —- ParseTreeWalker().apply { walk(object : KotlinParserBaseListener() { override fun enterFunctionDeclaration(ctx: KotlinParser.FunctionDeclarationContext) { val bodyChildren = ctx.functionBody().children if (bodyChildren.size > 1 && bodyChildren[0] is TerminalNode && bodyChildren[0].text == “=” && ctx.type().isNotEmpty()) { val firstChild = bodyChildren[0] as TerminalNode println(“Found explicit return type for expression body “ + “in function ${ctx.SimpleName()} at line ${firstChild.symbol.line}”) } } }, context) } —-

    The code is pretty self-explanatory and yields the following:

    [source] Found explicit return type for expression body in function hello2 at line 5

    Categories: Technical Tags: code qualitySonarQubeKotlinplugin
  • A SonarQube plugin for Kotlin - Paving the way

    SonarQube Continuous Inspection logo

    :imagesdir: /assets/resources/sonarqube-plugin-kotlin/

    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 serie is about creating such a plugin, and this first post is about parsing Kotlin code.

    == ANTLR

    In the realm of code parsing,[ANTLR^] is a clear leader in the JVM world.

    [quote] ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files. It’s widely used to build languages, tools, and frameworks. From a grammar, ANTLR generates a parser that can build and walk parse trees.

    == Designing the grammar

    ANTLR is able to generate parsing code for any language thanks to a dedicated grammar file. However, creating such a grammar from scratch for regular languages is not trivial. Fortunately, thanks to the power of the community, a grammar for Kotlin already exists[on Github^].

    With this existing grammar, ANTLR is able to generate Java parsing code to be used by the SonarQube plugin. The steps are the following:

    • Clone the[Github repository^] + [source] git clone [email protected]:antlr/grammars-v4.git +
    • By default, classes will be generated under the root package, which is discouraged. To change that default: ** Create a src/main/antlr4/<fully>/<qualified>/<package> folder such as src/main/antlr4/ch/frankel/sonarqube/kotlin/api ** Move the g4 files there ** In the POM, remove the sourceDirectory and includes bits from the antlr4-maven-plugin configuration to use the default
    • Build and install the JAR in the local Maven repo + [source] —- cd grammars-v4/kotlin mvn install —-

    This should generate a KotlinLexer and a KotlinParser class, as well as several related classes in target/classes. As Maven goes, it also packages them in a JAR named kotlin-1.0-SNAPSHOT.jar in the target folder - and in the local Maven repo as well.

    == Testing the parsing code

    To test the parsing code, one can use the grun command. It’s an[alias^] for the following:

    [source] java -Xmx500M -cp “<path/to/antlr/complete/>.jar:$CLASSPATH” org.antlr.v4.Tool

    Create the alias manually or install the antlr package via Homebrew on OSX.

    With grun, Kotlin code can parsed then displayed in different ways, textual and graphical. The following expects an input in the console:


    cd target/classes grun Kotlin kotlinFile -tree —-

    After having typed valid Kotlin code, it yields its parse tree in text. By replacing the -tree option with the -gui option, it displays the tree graphically instead. For example, the following tree comes from this snippet:


    fun main(args : Array) { val firstName : String = "Adam" val name : String? = firstName print("$name") } ----

    image::ast-inspector.png[AST Inspector,910,588,align=”center”]

    In order for the JAR to be used later in the SonarQube plugin, it has been deployed on[Bintray^]. In the next post, we will be doing proper code analysis to check for violations.

    Categories: Technical Tags: code qualitySonarQubeKotlinpluginANTLR
  • Why are you testing your software?

    Burned bus at a bus stop

    :page-liquid: :experimental:

    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 of that we had to use it to create an automated tests harness to prevent regression bugs. Later, this became an expectation: no tests meant no changes in the code for fear of breaking something.

    More recently, however, it happened that I sometimes have to advocate for the opposite: not write too many tests. Yes, you read that well, and yet I’m no turncoat. The reason for this lies in the title of the post: why are you testing your software? It may sound like the answer to this question is pretty obvious - but it’s not, and the answer is tightly coupled to the concept of quality.

    [quote, Wikipedia] __ In the context of software engineering, software quality refers to two related but distinct notions that exist wherever quality is defined in a business context:

    • Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced.
    • Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It is the degree to which the software was produced correctly. __

    Before answering the question of the why, let’s consider some reason why not I’ve already been confronted to:

    • Because everyone does it
    • Because the boss/the lead/colleagues/authority figures say so
    • To achieve link:{% post_url 2011-04-18-100-code-coverage %}[100% of code coverage^]
    • To achieve more code coverage than another team/colleague
    • And so on, and so forth

    All in all, those “reasons” boil down to either plain cargo culting or mistaking a metric for the goal. Which brings us back to the question, why do you test software?


    The only valid reason for testing is that resources spent in making sure the software conforms to non-/functional requirements will be less over the course of time than the resources spent if not done. ====

    That’s pure and simple Return Over Investment. If ROI is positive, do test; if it’s negative, don’t. It’s as simple as that.

    [quote] __ Perfect is the enemy of good __

    The real difficulty lies in estimating the cost of testing vs the cost of not testing. The following is a non-exhaustive list of ROI-influencing parameters:

    Business:: No bugs are allowed in some industries e.g. medical, airplanes, banks without serious consequences to the business, while this is less critical for others such as mobile gaming. Estimated lifespan of the app:: the longer the lifespan of an app, the better the ROI because the same amount of testing code will yield more times e.g. nearly no tests for one-shot single-event apps vs. more traditional testing for tradition business apps running for a decade or so. Nature of the app:: some technologies are more mature than others, allowing for easier automated testing. The testing echosystem around webapps is richer than around native or mobile apps. Architecture of the app:: The more distributed the app, the harder it is to test. In particular, the migration from monoliths to microservices has some interesting side-effects on the testing side. It’s easier to test each component separately, but harder to test the whole system. Also, testing specific scenarios in clustered/distributed environments, such as node failure in a cluster, increase the overall cost. Nature and number of infrastructure dependencies:: The higher the number of dependencies, the more test doubles are required to test the app in isolation, which in turns drive up testing costs. Also, some dependencies are more widespread e.g. databases and web services, with many available tools while some are not e.g. FTP servers. Size of the app:: Of course, the bigger the size of the app, the bigger the number of possible combinations that needs to be tested. Maturity of the developers, and the size of the team(s):: Obviously, developers range from the ones who don’t care about testing to those who integrate testing requirements in their code from the start. Also, just for developers, adding more testers is subject to the[law of diminishing returns^]. Nature of the tests:: I don’t want to start a war, suffice to say there are many kinds of tests - unit, integration, end-to-end, performance, penetration, etc. Each one is good at one specific thing, and has pros and cons. Get to know them and use them wisely. Strength of the type system:: Developing in dynamically-typed languages require more tests to handle the job of the compiler in comparison to more statically-typed languages.

    While it’s good to listen to other’s advices - including well-established authority figures and this post, it’s up to every delivery team to draw the line between not enough testing and too much testing according to its own context.

    Categories: Java Tags: code qualitytestingcode coverage