SonarQube As An Education Platform

Patroklos PapapetrouJuly 25th, 2014Last Updated: July 25th, 2014

2 64 4 minutes read

I’ve been using SonarQube [1] platform for more than four years. I remember the time when it was making its first baby steps as a code quality management tool. It looked more like a system that was integrated with various third-party static analysis tools (like PMD, FindBugs etc.) and provided a few but important code quality metrics. Many things changed over the next years. SonarQube today is considered a mature software eco-system (in my humble opninion the best) that provides a set of features for successfully applying the process of continous inspection to any development methodology.

In this article I’m not going to discuss about SonarQube’s star features that help you manage and control your Techinical Debt. I will give a different point of view and explain how you can use it as an educational platform.

Teaching developers with coding rules

Since release 4.0, integration of external tools has been gradually dropped off and several of the coding rules provided by these tools have been replaced by rules, written using an in-house developed (but still open-sourced) language parsing library which is called SonarSource[2] Language Recognizer (SSLR)[3]. One of the great benefits of this rule re-writing is that they include a very explanatory description about the purpose of the rule as well as several code examples – if applicable – that present the right and wrong way of writing code.

Let’s take a look at the following image which is a snapshot of a java coding rule that checks if Object.equals is overridden when Object.compareTo is overridden. As you see, the rule is not only backed-up by a very detailed and well-argued explanation but it also contains two code snippets: a compliant and a not-compliant one.

Developers are able to read all this information when they are looking at an issue[4] that violated this rule. They are supposed to understand what they did wrong, fix it and hopefully don’t make the same mistake again in the future. But hey!! You don’t have to sit down and wait for SonarQube to raise an issue so that developers read about the correct way of writing code. You can send the developers to study the rules anytime they want. In other words, educate them before a quality flaw appears.

In the company I work with, we have filtered out the rules that are not aligned with our coding style and then we grouped them by using the tagging mechanism provided by SonarQube [5]. Then, we organized training sessions where we walked through every rule of a specific tag(group) and we discussed the details of each rule and the suggested way of coding. That’s all! We noticed that the developers started writing better code from the very next day and SonarQube’s issues were very limited for the coding rules we have already discussed.

Learning from code reviews

If you don’t have enough time to allocate for the previous suggestion then you might consider an alternative approach. Most of you, are probably familiar with code reviews or at least know the basics and the benefits of applying such a practice. SonarQube provides a built-in tool that facilitates the code review process.

In a few words, each issue can be assigned to a developer and can be also planned in an action plan. Code reviewers are able to confirm the issue, can mark it as a false-positive case by providing some additional reasoning for that, or just comment on it with some suggestions or possible solutions to fix the problematic code.

All this issue-interactivity can be viewed as a way to teach people, especially young developers. Like the previous section, you can ask developers to read comments or study the raised issues. A nice way of doing this, without needing to cut time from your development tasks, would be the following. First prioritize SonarQube issues and plan them using action plans. For instance, you might have an action plan that includes all issues that should be fixed during the current iteration and another one for future iterations. Then try to hold short meetings during the iteration where you review all SonarQube issues and prioritize them. As soon as you finish and plan the required issues , let’s say for the current iteration, you can ask the developers to work as a team and come to a solution, especially for those issues that an one-line fix is not enough. Finally document the solution by commenting the relevant issues so that everyone can see it. The benefit of this approach is that developers are required to understand the underlying broken coding rules for all issues (not only for the ones that they created) and then figure out the fix.

Conclusion

Educating developers should be constant and continuous. But this is something that most companies forget, intentionally (lack of budget) or not (lack of time). If we try not to regard it as a necessary evil, but something that can take place during every day development tasks, then we might have a better chance. SonarQube’s coding rules and the easy-to-use coding review mechanism come to the rescue and can be put-upon to teach developers how to write better code and eventually make them better professionals.

This article was originally published at NDC Oslo Magazine 2014