In the article Code Quality Control And Why You Need It I described shortly importance of keeping high quality of code. This time, you will learn what are the 7 crucial elements that should be a foundation of any Automated Code Quality Control Process. This process can help you to keep your head calm and focus on important things.
The mentioned essential areas of the code quality control process are:
Let’s try to have a closer look at each of these.
“Clean code is simple and direct.
Clean code reads like well-written prose.”Grady Booch
Have you ever thought about how stylish is your code? Does your code read like well-written prose? Why is it so important?
Well, the way your code looks, shows how much you care about:
Even something as simple as inconsistent indentation can make code analysis a nightmare. And not to mention annoying and unnecessary merge conflicts.
Luckily, we can automate code style checking and correcting. Modern IDEs (Idea/Eclipse) can help you keep the code style correct by amending your code automatically.
Just remember to make the code style consistent across the team members. Each developer should use the same code style definition. Let it be a shared .editorconfig file or IDE-specific configuration.
Sharing the code style definition with your team is the first step. But, as long as we are talking about the process we need a way to check if everyone is following the code style rules.
The easiest way to achieve that is to integrate style checking into your build process. We can use Checkstyle and run it every time we push a code change to the repository. This can be achieved by using the Jenkins plugin or Maven/Gradle script.
So we have code style under control. But stylish code is definitely not enough to say that our code is solid.
Often, when we are working hard on solving a challenging problem and trying to meet deadlines, we may fail on following all the best practices.
Unfortunately, violating best practices can lead to serious consequences like:
Luckily, we do not have to spend hours scanning our code in search of simple, yet difficult to spot errors.
We can use one (or all) of the free tools that can do that for us:
Some of these tools can also identify duplicated code and find potential performance issues.
Similarly to Checkstyle, we can integrate these tools into our IDE and make code flaws checking a breeze.
There is one more option to make our code more robust. You can use the Checker Framework that enhances the Java type system and allows to add checks in code to prevent potential issues in the future. Requires some extra manual work while coding but it pays off.
But, again, we should always remember to make it run during the project building process. In case we forget to run it before we push our code to the repository.
In the previous section, we focused on finding common programming flaws in our code.
In this section, we will take a look at the code complexity. Code that is difficult to reason about is difficult to maintain and extend. And no one wants to work with such code.
Popular metrics for checking code complexity are:
To automate the process of code complexity checking, you can use the following tools:
Now let’s take a look at the design of your code and design flaws that static code analysis tools can identify.
Poor design (within the meaning of Object-Oriented Design) can cause the same problems as the high code complexity. Similarly, poorly designed software is difficult to understand, troubleshoot and change. So the cost of software development will be unnecessarily higher.
Again, do not expect a simple solution to resolve all the design issues. But, many Object-Oriented Design best practices have been converted into automatic source checks. These checks can prevent our code from becoming overcomplex (e.g. too high inheritance hierarchy) or oversimplified (e.g. God class).
Everything should be made as simple as possible,
but no simpler.Albert Einstein
There are many different rules for design checking but I recommend starting with those related to size violations.
Checkstyle and PMD offer a nice set of checks related to the excessive length of:
These rules might seem trivial. But you should focus on basics and ensure your code follows basic design rules first before you move on to the advanced ones.
So, we have covered basic design checks. But there is more our favorite static analysis tools can offer. Find some examples of the most useful rules below:
Besides, SonarQube has many size-related metrics and nice visualization of those.
If you are looking for a more advanced analysis of design problems, you can check the following tools:
Please note that these free for open-source projects only.
We all know that developers care about the security stuff. They do the code review with OWASP TOP 10 in hand. Moreover, they check the CVE database every day to make sure none of the 3rd party dependencies have any security vulnerabilities.WE DON’T
Is that OK? Definitely NOT.
We are responsible for making our code secure to the same extent as we are for making it extendable, maintainable, performant, etc.
The problem is that it is not that exciting as building new stuff, analyzing design challenges, or trying out new, shiny technology.
So, how should we do that? How can we make our code secure with the least possible effort?
Should we really check the code with an OWASP 10 list in hand? Well, unfortunately, it is not that easy. It requires deep knowledge in the security field. Besides, you need to know the internal workings of the technology used well.
To clarify, I am not a secure coding expert and probably will never be. Simply because I am focused on different areas of software development craftsmanship. But, it doesn’t mean I am not responsible for creating a secure code and delivering software that is free from known vulnerabilities.
Below you can find basic security-specific knowledge resources that every developer should know:
But before you become Secure Coding Master, let’s add some automation to the code security checking.
Below you will find 2 tools that can automate the security checking process:
There are two more, security-related topics, that should also be part of every Code Quality Control process. These are 3rd Party Dependencies and Docker Images security scanning. But, as these are not strictly related to our code, and to make this article shorter, I will discuss these topics in a separate article(s).
Now, when our confidence level of code quality is high, the time has come to check your code coverage.
You can’t keep a calm head without a decent number of automatic tests, which you can run often and fast, to check if your code still works as expected. Furthermore, you can’t safely refactor your code quality without automatic regression testing.
“Code without tests is bad code. It doesn’t matter how well written it is. It doesn’t matter how pretty or object-oriented or well-encapsulated it is.”Michael C. Feathers
Unfortunately, sometimes we do not write proper tests that cover our code. This may happen e.g. when we struggle to deliver another release on time. Or we write tests but not covering all the possible flows. Because of that, we need some metrics to check if our code has been sufficiently tested or not.
There are many different test coverage metrics. But the most important are:
To calculate the coverage of your code you can use your IDE features. Two popular options are Coverage in IntelliJ IDEA and JaCoCo in Eclipse.
Using coverage tools inside your IDE gives you the opportunity of seeing which parts you have covered and which not right in your code editor.
Of course, we can’t forget to integrate Code Coverage calculation into our build process. This will ensure we are not falling short on testing our code by checking the metrics continuously.
JaCoCo is also used by Sonar which allows for monitoring how your code coverage changes in time. You can also define alerts if a new code coverage level is too low (Quality Gates notifications).
Alright, we’re getting closer to the end of a list of crucial elements of the Code Quality Control Process. The last element to cover is Code Review.
Code review is the most complex and problematic element in the whole process because:
Let’s take a quick look at each of these problems.
I do not know any tool that can completely automate the process of code review. But all the steps we have covered so far are actually kind of automation of the Code Review process.
In other words, the more elements of the process we cover by automatic analysis the less we will have to do during a Code Review.
And this is actually very good news as the fewer things you have to think about at the same time the better the results should be. And the whole process becomes less error-prone at the same time.
So now, you can do a proper Code Review by focusing only on the elements that automatic code analysis did not cover:
Merge/Pull Request Decoration is something you should has a closer look at if you are looking for more automation in the Code review process. This feature is very convenient if there is a lot on your shoulders and you strive to cut unnecessary actions.
It is much easier to log into your SCM and see the static code analysis results right in the code when you open a Merge Request.
You can find this feature in SonarQube (available in paid options only).
Developers conduct Code Review in various ways.
One focuses mostly on a design side while the other is a performance freak and analyzes the time and space complexity of every line of code.
On one side it’s good as there are different views on Code Quality in a team. But on the other side, the result of Code Review might be different depending on who performs it.
And that is not that good at all.
So to make the code review process more consistent it is good to have a Code Review checklist. Such a list should show what to check during the manual code verification process.
I like Google’s Code Review Developers Guide. It is a bit long read but you can always prepare a shortlist out of What to look for in the Code Review section so that every developer in your team knows how to approach Code Review consistently.
So that would be it. We have covered 7 elements of the solid Code Quality Control Process. It might seem like something very complex and difficult to implement. Even unachievable. But you don’t have to build the whole process at once.
If you haven’t used any of the tools described in this article before, then adding one of them should make a difference.
Of course, there are other aspects of implementing the Code Quality Control process. If you are starting a new project then building such a process shouldn’t be a problem as the technical debt is probably not that big. But, if want to start controlling the quality of the code in the legacy system, then you should prepare yourself for war with technical debt first. It may take a while before the static analysis tool that you chose, shows no warnings at all (assuming you haven’t turned most of the rules off…).
Department of Information Technologies: https://www.ibu.edu.ba/department-of-information-technologies/