Code quality is an area that isn’t always considered to be a top priority, at least as long as the software does what it should, more or less. However, with a few common sense decisions, and the use of Java code quality tools such as SonarQube, you can keep your work clean and tidy.
Quality is essential no matter what you do, and which industry you’re in. It’s a simple enough fact – you can work quickly and efficiently, but if the end result doesn’t meet the required quality standards, all that effort won’t amount to much.
The problem is, in the fast-moving world of the 21st century, quality often suffers because of time or budgetary constraints. You know the project management triangle, right? Fast, cheap, and good – you can pick two of these, but never all three.
The above is true for software development too. One of the areas that can be problematic is code quality. Good practices and cooperation between team members are crucial here, but you can also use static code analysis tools such as SonarQube (previously known as just Sonar) to make things a bit easier.
In this article, I’ll tell you what we do at Pretius to make our code clean and tidy – and why it’s imperative to do so.
Code quality is subjective, which means “good” may signify something slightly different depending on the developer, project, and specialization. There are, however, several universal factors to consider and questions to ask when judging code. Some of these questions also point towards potential problems you can face due to bad code quality.
1. Does the software do what it should?
It’s the main question, really, and the most obvious way to identify possible code quality problems. Badly coded software can work in the short term, but problems tend to stack up over time, and issues are bound to arise at some point in time. Lack of code quality verification can lead to unintentional duplications, unnecessary complexity or even unpredictable “black boxes” which are the seeds of errors, instability, and even security problems.
2. Does the code follow known patterns and keep consistent style and structure?
You can’t always assume the current development team will be the only one working on a given piece of software. New people can be hired over time, and sometimes companies decide to go with a completely different vendor for a new feature or integration. Because of this, code should be easy to understand by people who didn’t write it, and it should follow a defined structure so that it’s easier to onboard new developers whenever it’s necessary.
3. Did you test it? What are the results?
One of the fundamental ways to find flaws in code is to test it. Good code should be easy to test by unit and integration tests (depending on the frameworks and technologies you use, there are ways to make integration testing almost hassle-free). It is much easier to write tests for methods with concise inputs and outputs or classes which have clearly defined responsibilities and limited and well-thought dependencies. In fact, static code analysis tools may help you keep an eye on some of those factors.
4. Is it secure?
There’s an industry saying that “The best code is no code at all”. However, if coding is required, the code should be simple, clean, consistent, and free of errors. It should also be secure, which means it’s free of vulnerabilities (for example, it shouldn’t depend on libraries that are known to be unsafe), and it has properly configured security mechanisms.
The most important thing to point out is that no code quality tool will be able to replace good workplace practices and communication between team members. We do use SonarQube and PMD in some of our projects (the decisions are made by our teams, on a case-by-case basis), but we also ensure great code quality via a couple of other means.
A good team is key
To write good code, you first need to have good, responsible, and reasonable coders (though it doesn’t mean everyone has to be a Senior Java Developer with 10+ years of experience). However, even more importantly, you need people who understand each other and know how to cooperate. This is crucial because one of the best ways to reveal problems and inconsistencies in your work is to ask other developers to review the code.
The best candidates are always people from your own team. They know the project and its business context just as well as you do, so they can understand whether your code does what it should. At Pretius, we often use GitLab for such peer review.
Another good idea is to define typical conventions, such as naming, solutions for typical problems, etc. Keeping this kind of documentation can help unify coding practices between team members. It’s important to point out it doesn’t have to be a huge, complicated document – a simple file people can quickly scan through and memorize is usually much better. You can also keep editor configuration files (e.g., the well-known .editorconfig) to ensure the same basic formatting or use Git hooks to automatically apply consistent code formatting.
A consistent style and structure of code will make both the cooperation between team members, and the introduction of new people to the project much easier.
Test your work
Even seemingly “clean”, and “proper” code can sometimes turn out to be useless in practice. Because of this, testing is such a crucial part of the development process. Unit testing and integration testing help you ensure proper quality and identify issues when there’s still time to fix them. Tools such as SonarQube help you monitor the test coverage, which is how much of your code is actually being tested.
Ensure proper architecture
However, it’s also worth pointing out that testing isn’t all. Another thing that can help you write good code is well-planned system architecture.
Every piece of code needs to be considered in terms of the architecture: which layer of the system it applies to, and where it should be found. Also, ask yourself if what you’re trying to do wasn’t already done somewhere else. Does it really need a dedicated module? It’s worth discussing all of this with the team before development – during code reviews, architectural changes are very difficult to repair.
And, last but not least, use proper Java code quality tools!
Static code analysis tools such as SonarQube or PMD can help you improve your code quality by scanning your work and pointing out various problems and issues. SonarQube is our tool of choice because we found default SonarQube rules more relevant to our projects. It allows you to scan not only the entire project but also changes made since the last review (PMD is also fine, but a bit more limited).
You can use a SonarLint plugin directly in your IDE and make it scan the code you write. It can make the code review process considerably less time-consuming for you and your team as you fix the issues before anyone sees and discusses your code.
SonarQube can be plugged into the project-building process with a Maven or Gradle plugin – SonarScanner. Reports generated by the plugin can be used in two useful ways. You can publish them to the SonarQube server, which offers detailed reports that analyze the code and point out problems in several areas, such as code smell (general “feel” and quality), security, duplications, etc. It also shows you how each quality metric changes during your application growth. You can browse all reports in a web application.
You can also use those reports in a separate step in the CI/CD pipeline in your favorite tool (it works with platforms such as Jenkins, Azure DevOps, and so on) and introduce quality gates for new code. Change that does not meet predefined quality conditions will not be allowed to be merged or deployed.
The most important factor when it comes to keeping your code clean, tidy, and working as it should, is to have a good team behind your back. A well-organized, orderly workspace, with clear rules and guidelines, and a well-defined development process that ensures proper system architecture and testing also helps a lot.
Static code analysis tools are just a small piece of the puzzle of software development, but they’re still worth checking out. SonarQube is flexible and quite easy to set up. It won’t do all the heavy lifting for you – nor should you expect it to, really – but it’ll definitely help you keep a finger on the pulse. At the very least, it’ll certainly help you detect and avoid mistakes and sometimes spare a lot of time analyzing bugs or even outages. Also, the number and variety of SonarQube rules allow even experienced developers to learn something new.
Java code quality tools FAQ
Here are answers to some of the most popular questions regarding Java code quality tools you can find on the Internet.
Which tool is used for code quality?
SonarQube is a very popular static analysis tool. It has broad language support and can be used in your IDE, or as a separate part of the CI/CD pipeline.
What is SonarQube used for?
SonarQube is a static code analysis tool – a piece of software that allows you to scan the code you write to make it better. It helps you find problems and issues.
How SonarQube can help me?
Example of tasks SonarQube will do for you:
- check your code against thousands of quality rules
- find bugs and security vulnerabilities
- track test coverage
- measure and estimate technical debt
Who uses SonarQube?
SonarQube is a code review tool for software development teams, so it is used by software developers, DevOps engineers, QA specialists and even managers who can monitor product quality. It’s used in various industries and companies, including Boeing and Intel.