Things That You Can Do to Improve Code Quality
How you can bring down the WTFs per minute
Poorly written code can be a real disaster. When the mess in your code increases, so does the time that it takes to maintain it. In the worst-case scenario, the code can no longer be maintained and the project will slowly die.
To prevent this situation you should take care of the quality of the code. You should invest time in the quality of your code. In the long run, good code pays for itself.
Quality is everyone’s job. It doesn’t matter if you’re the manager, a tester, or a developer. The delivery of high-quality, and of course working, code should be the goal throughout the development process.
Here’s a list of six things that can be done to improve code quality. Some of these things can be done as an individual, others are more of a team effort.
1. Four-Eyes Principle
The four-eyes principle is an easy principle to understand and execute. It means that at least two people, including the author of the code, review the code. One of the most popular methods nowadays is the pull request method.
Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
During a code review, several things should be taken into account. One of these is checking whether the code breaks the code convention rules. This is a process that can be automated by using a linter in a pipeline, but sometimes this check is still performed manually.
Other things that can be checked for, which cannot be done automatically, are the maintainability of the code and error handling. Last, but not least, the code should be checked for completeness. Does this piece of code contain the entire scope of the feature as it was intended to be built?
2. Continuous Integration
“But it worked on the development server”. Or even worse: “It worked on my machine”.
Issues and discussions of this nature are what you want to prevent from happening. This is exactly where continuous integration (CI) can play a huge role.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
— Martin Fowler
The point of continuous integration is that it gives developers a lot of feedback rapidly.
Continuous integration works when you follow two simple rules:
- Keep the build fast. Nothing is more discouraging than a build that takes up to an hour.
- Fix broken builds immediately. The whole point of continuous integration is that you’re always developing on a known stable base.
Continuous integration improves code quality because it gives rapid feedback to the developers. If a test fails the build will fail and the developer will be notified. Furthermore, it is preferable to add a linter to your build script that checks for coding conventions. This increases code quality as well, obviously.
3. Coding Conventions
It is important to have a list of coding conventions. But before you start making a list of coding conventions everybody in the team should be on the same page. This probably will go hand in hand with a lot of discussions about the preferred conventions.
Make a list of coding conventions where you document how variables should be declared and some naming conventions, etc. The number of rules that you can add to this list is unlimited, and the number of rules can vary. Just do what works for you and your team. Feel free to add new rules to the list of conventions if the team feels like it. The same goes for removing a convention from the list.
Once you’ve got your list of coding conventions it is extremely important to stick to them. As I mentioned, the most preferable way is to check the coding conventions with a linter in the pipeline, since it doesn’t require any manual actions. If that’s not an option, install the linter on your local environment. Just make sure to use the linter regularly, at least before every commit. This will increase the readability and maintainability of the code base a lot since code is more uniform.
High-quality code can speed up long-term software development since it can be reused and developers don’t have to spend that much time fixing old bugs and polishing code. It also makes it easier for new people to join the project.
4. Test, Test, Test
The fewer bugs the code has the higher its quality. Thorough testing filters out critical bugs, ensuring that the code works the way it’s intended.
Having a clear test strategy is essential when it comes to improving the quality of the code. As a bare minimum, your code should be unit tested. If you want to do other ways of testing, like integration testing or regression testing, that’s even better.
According to the test pyramid, the largest amount of tests within a software project should be unit tests. The reason for this is that they are cheap and fast. There are a lot of different tools available that can help you with creating unit tests and code coverage reports.
Running the test suite and creating a code coverage report can all be done automatically via continuous integration. It is even possible to make a build fail when the code coverage doesn’t meet the required percentage.
5. Analyze Bugs
Having bugs in your code is probably inevitable. The way these bugs get handled is very important. If you want to improve yourself as a developer it is key to learn from your mistakes. That’s why you should analyze bugs.
When a bug occurs, analyze the impact of the bug. Is it a low priority or a high priority bug? If it is a high priority bug, it should be fixed immediately.
When analyzing bugs it is important to ask yourself some questions. What went wrong? Why didn’t we test this (properly)? At what other places does this occur? And most importantly how can we prevent this from happening again?
Of course, tooling is available that helps you tracking bugs. There are a lot of bug trackers available on the market. Pick one that fits your needs.
The only real mistake is the one from which we learn nothing — Henry Ford
6. Start Measuring
When it comes to measuring there are several metrics you can use to quantify the quality of your code.
The number of defects, and the severity of those defects are important metrics of overall quality. If you want to keep track of the defects you could use a bug burndown chart, for example. A bug burndown chart works just like a normal burndown chart in Agile software development. The only difference being that the bug burndown chart contains the number of bugs that are unfixed, instead of user story points.
Complexity is often measured with the cyclomatic complexity metric. It is a quantitative measure of the number of linearly independent paths through a program’s source code.
There is a correlation between the cyclomatic complexity number and the frequency of defects:
A number of studies have investigated the correlation between cyclomatic complexity number with the frequency of defects occurring in a function or method. Some studies find a positive correlation between cyclomatic complexity and defects: functions and methods that have the highest complexity tend to also contain the most defects. However, the correlation between cyclomatic complexity and program size (typically measured in lines of code) has been demonstrated many times.
Making the code less complex should, in theory, lead to fewer defects.