6 ways to improve your code quality

During JavaOne I attended a variety of sessions covering topics from how to use Docker containers to potential issues you may face when migrating to Java 9. One talk that we found interesting was Twelve Ways to Make Code Suck Less by Ward Cunningham whom highlighted the importance of having good code quality.

Ward Cunningham speaking about code quality at JavaOne

According to Cunningham code quality is an important task you should pencil in alongside your development tasks. Low quality code can cost you both time and money as it takes longer to be understood and can just generally be a pain to work with. Developers would be wasting precious time they could be using to work on a cool new feature for their product or service.

From Cunningham’s presentation I chose my favorite 6 methods you can incorporate to improve your code quality and lower technical debt.

1) Schedule Time To Lower Technical Debt

Like every important task you have to make time for it. The easiest way to do this is to give your developers time to actually go back and maintain the code base. Having dedicated and prioritized time means the task can be focused on instead of someone trying to complete it in bits and pieces when they have a spare 5 minutes.

Odds are developers already know where code could be improved but they just never get round to fixing it because they already had so much else on their plate that needs to completed first.

2) Clear Code > Clever Code

There are multiple ways code can be written. Even something as simple as traversing an ArrayList to find a given value can be accomplished various ways. You could use the humble for loop and if statement, a while loop, a for-each loop or even a lambda if you prefer them. With such a simple example any suggested method would be quick to read and understand but a complex method with lots of conditionals, loops and lambdas with parameters that have names like ‘i’, ‘j’ and the dreaded ‘k’? That is when code starts to become complex and developers have to spend a little time trying to understand what is happening.

When writing code you need to keep in mind the person who is going to read your code. Is it going to be easy for them to follow the code through and understand what everything does? Are your variables and methods adequately named? Code should be optimised for reading and you need to remember if you sacrifice quality to get performance then you may get neither.

3) Tactical Code Reviews

If you have not got a rule on code having at least one reviewer then you may want to change that soon. Having a second or third developer peer review your code helps to greatly reduce code defects. Peer reviews complement testing as other developers can write test cases to check the code does what it is supposed to do. Tests need to be created/updated when new bugs are found to make sure the fixed problem is not re-introduced.

4) Comment Why, Not What

If you find a piece of code that is heavily commented then that is usually a bad sign. Good code is like a good joke in that it should not need explaining. The code in question needs to be reviewed and refactored until it can be understood without the comments having to tell you what is happening. That is not to say that you should not use comments but they should be used effectively and not to cover bad coding. Write expressive, self-documenting code in the first place to avoid this.

5) Avoid Accidental Coding

Accidental coding is caused when you do not fully understand the code and write a piece of code that just works without testing it. Further down the line this piece of code could end up breaking when certain unplanned conditions are met. This can cause other code to have to be rewritten and unplanned work that needs to be carried out. To avoid accidental coding you need to avoid working in desperation and make sure you understand how code works. Corner case tests could also be useful.

“When I wrote this code only God and I knew what it does. Now only God knows…”

6) Avoid Primitive Obsession

Instead of creating general code yourself, use other’s if it is available. There is no need to reinvent the wheel just to show you can. Imperative programming is packed with accidental complexity because of side-effects so if someone wrote code that has been used for a while and is relatively bug free then use it.

Good code should be a story not a puzzle. Its up to you to create something that is easy to follow and understand not something that will have someone scratching their head for hours.

So there you have it. Hopefully those 6 points will get you started on reducing your technical debt and improving not only your current code base quality but help steer you away from some bad practices in the first place. Do you have any tips for improving code quality?