Very often, members of a development team are concerned about different coding styles. However, even though there are guidelines on best practices, many teams consist of members who work at different times and have different levels of experience, leading to unclean code in different situations.
A known solution to this type of problem is the use of tools that allow for analysis of code repositories and early detection of different factors that may affect short, medium or long term. This article contextualizes some of these tools, but it will focus on one in particular that helps write clean code from the beginning.
The company Sonarsource has different products that help us on the path to always having clean code, these are: SonarCloud, SonarQube and SonarLint. Regarding SonarCloud and SonarQube, it can be said that they are similar tools. A section of an article on their blog mentions the following:
“The foundation: Static code analysis for 30+ languages.
Both products essentially cover the same languages (SonarCloud does not support PL/I, RPG or VB6). Both share the same underlying static analysis engine to detect errors, vulnerabilities, and code smells and generate valuable code quality metrics.”
SonarQube vs SonarCloud?
The static analysis engine referred to scans our entire repository or parts of it to measure reliability, security, and maintainability, and then presents valuable metrics in a user-friendly interface. This interface can be SonarQube or SonarCloud. While SonarQube is hosted on local servers or self-managed cloud, SonarCloud is hosted and managed by SonarSource on AWS. The free version of the latter only analyzes public repositories, so which one to use? Here’s an extract:
“In summary, if your team is completely cloud-based, you don’t want maintenance problems and want the fastest access to new features, then SonarCloud is an excellent choice. If you agree with self-hosting and maintenance or see value in management capabilities, then SonarQube would make sense for you.”
I have noticed the use of these tools in various teams, especially SonarCloud, analyzing the code at the end of the development of a functionality taking advantage of the integration with DevOps using CI pipelines. However, this means that only at that moment the developer can notice if they have something in their code that is not suitable to add to the main branches, which indicates a rework in development and possibly tests. This sometimes affects the team’s morale and confidence because it does not allow them to visualize the changes theoretically already ready in any of the environments.
At this point, one can think carefully about the phrase from Sonarsource: “Clean code starts in the IDE,” and for this, the other tool is contextualized: SonarLint.
According to Sonarsource’s definition:
“SonarLint is a free and open-source IDE extension that identifies and helps you solve quality and security issues as you code. Like a spell checker, SonarLint scribbles or highlights defects and provides real-time feedback and clear correction guidance to deliver clean code from the start.”
This tool is available for various widely used IDEs such as VS Code, Visual Studio, Eclipse, PyCharm, Android Studio, among others. Reinforcing the idea, this allows us to know in real-time if something in our code is not suitable.
All the tools together allow developers to achieve writing clean code, improve code quality, and enhance their programming skills. However, SonarLint, in addition to highlighting the code fragment, provides information on why that fragment is not suitable and how it can be refactored to meet high-quality standards. This is a way to help the developer become aware of shortcomings in their skills or knowledge of standards, and by having to correct or adjust, it encourages continuous improvement of their abilities. On the other hand, the information that Sonar provides regarding each evaluated rule is presented differently in each IDE but is very clear, assertive, and reasonable.
Let me give an example of using SonarLint in VS Code. First, it is downloaded and installed as an extension.
Previously, we must have configured a project in SonarQube or SonarCloud and have in mind two concepts: “Project Key” and “Organization Key,” but also have a Sonar user token. This is necessary for any of the supported IDEs, and Sonar has excellent documentation for the rest of the IDEs. However, the idea is the same.
We must configure the connected mode in the Sonarlint extension.
We add the server URL, for Sonarcloud it is: https://sonarcloud.io/, but if we are using a local server we put something like: http://localhost:8080/ or the URL of any other self-managed server as appropriate.
User token generated from the SonarQube or SonarCloud interface in the “My account” section of the menu that appears on the top right where we log out and then in the “Security” tab. In the case of VS Code, there is also the option to use the “Generate Token” button.
In the configuration, we will be asked for the “Organization key,” which is basically how we identify the organization we want to connect to.
Once connected we can select the project with the “Project Key” or the name we identified it with.
All this will allow us to access the specific rules and conditions of our project or what is known as “Quality gate” and “Quality profile”, but if we do not configure any organization or project, Sonar will use the default profile called “Sonar way”.
All set! Now we can start visualizing in our IDE the rules and conditions that will allow us to have high quality code.
Suggested flow by Sonarsource.
Image taken from SonarQube Documentation.
In this region there is a saying: “Prevention is better than cure,” and it fits well with the description of this flow, but finally, I will share something from my personal experience.
Sometimes, to ensure that the code met the organization’s conditions and rules, I did not connected the IDE to SonarCloud rules but also configured a local server with SonarQube that had the same conditions and rules as SonarCloud and ran a local scan before pushing the code to the main branches. At this way, I could keep more standards in mind, which helped me continuously improve my skills, reducing the number of failures in CI pipelines and generating trust throughout the team.
In conclusion, we can generate greater confidence that our code can be clean as we type, and in that sense, the quality of our development increases. We will also have more time to be creative and increase our potential without worrying about reprocessing, with the feeling of always delivering quality in our work and contributing to high-performance teams.
The source code is the most valuable asset of our software. Nowadays, all systems need to have a high level of variability and trust. Therefore, it is essential today to have tools and practices that allow us to achieve clean code. Among the advantages, we can mention cost and time reduction, a pleasant work environment since it increase a culture of high-quality work, and high-performing software for a long time, as maintainability is facilitated.
We generate value through clear content, focused on the software development industry.