Code Quality is a topic that often results in very heated discussions. These mostly, if not always, are about details, such as tabs vs spaces, about interfaces versus abstract classes and what constitutes good “Javadoc”. These discussions often boil down to a lot of yes/no arguments during Code Reviews, almost always revolving around Code Style. What we’re trying to achieve with code reviews is a higher quality of our deliveries. But how we define quality of our deliveries? Edwards Deming defines “Quality as the ability to get more done at a lower cost.” So when it comes to software quality, a higher software quality means we get to implement more features with less effort. As such, code reviews should focus on what we can do so that in the future we get more done in less time.

In my experience, there are a few things that can be annoying and cause frustration. Then there are the things that can cause the big “oh crap” moments during the development process. These “oh crap” moments are often very late in the process and have a very high impact. Also, they tend to be the result of hasty decisions and a reluctance to fix critical issues sooner. Often, feedback in code reviews is “this part is not indented correctly” and “why did you add an interface here?”. When in fact things should be about “why didn’t you create an abstract super class for all this stuff, now we’re stuck copy pasting the same stuff over and over again”, which is something that rarely comes to the surface.

Then there’s the question when will you fix an issue with the quality of your code? When do you fix an issue that’s not yet an issue? There are two approaches you can take here, and you should apply both! Firstly, you plan for quality, don’t consider a task or feature to be done unless you are satisfied with the quality of your code. Make sure you are focused on this in the beginning, when nobody is stressed (yet). Secondly, sell your issue by making sure you make very clear on what the impact is of doing something a certain way. Make sure you help sell this to whoever needs to maintain what you’re delivering. This can be a line manager, but it could also be the to-be project manager.

In short, we should aim to change the traditional Code Reviews that focus on Code Style and instead focus on the Code Structure to ensure a higher quality. If you still insist Code Style is something you want to review, ask yourself, what are you trying to gain?