Code Analysis Tools: SonarLint

This is a very short article on an extension that is readily available across different code editors for running code quality analysis. So, I’d talk a bit about SonarLint, which is simply a linter that helps developers with detecting and fix quality issues on the go. So, in a very simple sense, SonarLint automatically shows you where and what exactly are the issues with your code, against professional quality coding standards, practices and conventions as of a spell checker. So, its purpose is to give instantaneous feedback about how and what you code as you type in your code. Anyhow, this also relates to what is called ‘Static code analysis’, by a definition is – “is a method of debugging by examining source code before a program run by analysing a set of code against a set (or multiple sets) of coding rules”. 

Quality is an important aspect of a good software. But, typically in the case of undergraduate projects, code quality is something that is typically dusted under the mat which doesn’t indicate a good attitude or consideration towards to quality as well. But, in an industry perspective, code quality is really important since often than not, a product need to stay alive for a good long run to be profitable enough and what could a technically reeling software could possibly do with that, when it may be hard to adopt to changing market demands, new markets etc. with your code? So, often overlooked, being aware of static code analysis as a tool for improvement is a simple, least costly, yet highly impactful way of cutting down any re-work it there associated costs apart of techniques like adopting proper design patterns and well architecture application design. So, will discuss pieces of this one by one. 

Where does Static Analysis fit in Software Product Development Life Cycle? 

In one of the technical sessions, we discussed what DevOps is, what it is and what not along with the different practices in DevOps in maintaining a constant sync between all the different aspects of a software product. In that sense, static code analysis is performed early in development stage, before software testing even begins and therefore, for organizations and teams actively practicing DevOps, static code analysis is a way of creating an immediate automated feedback loop for the developers specially to inform issues with the code early on if there are any problems in their code so that in the long run, the chances arising on maintainability, sustainability, scalability etc. are managed effectively that long run software delivery issues such as the ‘Delivery Spiral’ caused by accumulated technical debt are proactively avoided. So, we are certainly look at the root causes and fixing them – sounds familiar doesn’t it? So, in other words, this is one technique to incorporate to deliver fast whilst maintaining incredible levels of quality. 

What are the advantages of Static Code Analysis? 

We’ve already discussed where static analysis fit in the whole DevOps realm. So, in that respect, why static code analysis could be boiled down to 3 major reasons: speed, depth and accuracy. 

 

Speed refers to the fast feedback we’ve been discussing. Compared to manual code review process, static code analysis tool would be much faster given its automated nature. Apart from the fact that, manual reviews could be subjective as well, static analysis could maintain objectivity across all code lines and programming languages. Therefore, the scale in which the code is measured will be uniform as well atop the fact that this too adds to the speed since both in terms of rectification on the go and specificity in the remedial actions (low decision time), issues could be attended a pace.  

 

Depth is concerned of the capability of code analyzers to cover all most all the code paths/lines in even the most complex of codes, which is undesirable by a manual tester.  

 

Accuracy is ‘objectivity’ that was mentioned before where manual reviews could be prone to errors – lack of coverage, mistakes, skips etc. whereas analyzers may scan every line of code to identify potential problems, verifying higher quality code. Hence, the bottom-line assurance to quality when checked against a standard set of rules is would be much stricter and compliant compared to lesser formal methods of manual testing.

SonarLint vs SonarQube/SonarCloud

SonarLint is a code editor plug-in or an extension. So, it works only on the IDE such could be either of IntelliJ, Eclipse, Visual Studio or VSCode for that matter. This allows, for the real time feedback to the developer. SonarQube on the other is a centralized service – which means, to get the service, you should be subscribed and authenticate, that conducts full analysis on the committed code typically triggered by either a build, or a commit in the Continuous Integration (CI) setup. Therefore, the purpose of SonarQube is to provide a comprehensive overview of the quality of the entire code base prior to being deployed into an environment. 

 

Typically, industrial teams would consider static analysis as a quality gate as well. The idea is to maintain or lower the defects in code under a pre-decided level of minimum quality indicated by different metrics of the code or to not allow any additional defects into production as of the current state, which could define the deploy or not decision as well. In any case, static code analysis dashboards are meant to provide visibility into the quality of the code for the team and may even be used to “stop the line”, apart from incidents like build failures to rectify the code before a proceeding deployment. 

However, both SonarLint and SonarQube or SonarCloud rely on the same static source code analyzers, most of them being written using SonarSource technology. So, often than not, in either case, a similar result could be achieved.

Installing SonarLint in VSCode

Easy... Just find Extensions of the icon for it in the side panel of the editor, click on it. Type ‘SonarLint’ in the search bar and hit enter. Once, the searching is completed, install the SonarLint extension that is listed there and that is it. 

But, make sure, before the extension is installed a JRE is installed in the local machine with global configurations since the extension would depend on Java in the run time. There is not specific version in particular, but make sure to do through the documentation of the extension to make sure that a proper compatible version of a JRE is installed.

Problem description and how to fix

In VSCode and other supported editors, SonarLint highlights the particular issues inside the code. As a developer, it’s just a matter of hovering on the highlighted areas to show the description of the issue. Often, these descriptions also come with suggestions for refactoring, which could be easily adopted into the code. 

Additionally, the developer could navigate to View in the menu bar and click on Problems to view the problems tab. This would list down all the problems in the code according to static analysis for the active opened file.   

Changing Analysis Rules

Managing analysis rules are fairly easy in SonarLint. Basic sonarlint extensions would only allow to activate, deactivate or completely remove already existing rules. Each of these rules, are provided with a very descriptive description alongside suggestions and examples. In either SonarQube or Sonar Cloud, the priority and severity of a violation of a rule could be modified but, it will not be the case in SonarLint – these are fixed. By default, not all rules are activated and therefore, the team should consciously decide on what rules the teams would want to focus and apply necessary number of rules accordingly. Therefore, the quality standard compliance level is a technology management decision. 

Sonar cloud is super simple and easy to use although it may have a decent impact on your quality coding practices. So, also for the fact that this being a strong encouragement to using this tool, on a long run intuitively will help in improving your code too.