What to look for in a code review

I’ve been with Inloop for exactly three years now as a software engineer. After many projects, clients, different challenges and many different team members to work with, I still consider one part of the development process to be the most influential when it comes to improving code quality over time: code reviews.

Being a development agency, we consist mostly of multiple small teams, each working on a specific project. We rarely see large teams of people working on a single platform. Detailed and strict code reviews make it possible for us to achieve high code quality even in this challenging setup, since it’s hard to appoint just few people to be responsible for the whole code base of the company.

Never forget

There are countless articles, best practices and guidelines to help you do better code reviews. Often, it’s not about a lack of resources or information, but about remembering all of these on a daily basis and never lowering your standard or making risky compromises for various reasons, like, for example, lack of time. This is the most important reason why I even chose to write this article, to remind ourselves once more again.

Basic principles

If you are a software engineer, then you should be quite familiar with principles like DRY, KISS or SOLID. If you are not, I strongly recommend that you take the time to read about them. Usually, when you talk with your colleagues or other software engineers, everyone seems to be quite aware of most of them. Yet, we, myself not excluded, often write code which is missing even these basic principles. Not because we choose to simply ignore them consciously, we just forget about them when we write the code, or it isn’t clear at first glance how to apply them correctly. That makes it much more hard and important to not forget about them during our code reviews. This is usually the first thing I look for when I do code reviews.

Uniform architecture

When people change teams, projects, they usually bring former habits with them. The usual ways of solving problems, connecting different parts of the system, layering the system. We can call this architecture. Different projects, different requirements, and people will almost always create at least small differences in architectures across projects. It is therefore necessary to aim for uniform architecture in your projects at least, so you don’t create a mess with your code. This is the second thing I look for when I do code reviews.

Letting your code go is good

I love to remove code, even more so when the code is mine. I am always thrilled when I can replace a bunch of my code with some simple library, knowing that most probably I am reducing the time necessary for people to onboard our project. I love also knowing that am reducing bugs when using a solution that is used across many projects, instead of just one. Learning to be happy about discarding your own work is often very hard and must be embraced when needed. This is usually the third thing I look for when I do code reviews.

Uniform code structure and style

There are always those little decisions, like how to name variables, how to structure your project, how to package classes, etc. They might seem not as important in the beginning, but later into the project they can still make the difference. If your code is structured and written uniformly, your variables and classes named and placed consistently, then the world becomes a much simpler place to inhabit. In such a world like this, you make less errors, issues get returned less times and in the end, everyone is happier. This is why code structure and style is the fourth thing I look for when I do code reviews.

What do you get out of it all

Of course, at the end, code reviews cost and they are not cheap so you have to get something for it. From my experience, I spend almost one quarter of development time on a certain issue doing code reviews. But, you always get:

• Knowledge across projects and context from your teammates. You always learn about the functionality, the problems your teammates are struggling with, and also new solutions that you might use when you (inevitably) reach similar problems.
• Consistency of the code style, naming conventions, but most importantly, consistency in architecture. If you have a common approach how to solve usual problems in your apps, code reviews are perfect way to enforce them.
• A lower bug ratio— that is, when you merge knowledge and consistency as mentioned above. Both of them are very strong prerequisites for error-prone software engineering. If you know what the other code is doing, and when it does so in a consistent approach so that you’re able to handle these sorts of problems the same way everywhere, you’re left with a lot less room for bugs to occur.

Where are tests?

I am sure that many of you would argue that I should be mentioning tests, and should have mentioned them much earlier. Test driven development is something that we also see important yet struggle to include it in a daily routine of our development process. Having said this, from my personal point of view, tests are another tool, complementary to code review, that helps ensure code quality. Tests are also such a huge topic that you would expect a separate article on them and hopefully in the near future ;)

Let’s sum this all up

As I mentioned at the beginning, it’s not about not knowing, but, rather, about reminding ourselves on each step of the way:

• Never let anything disrupt the process by which you ensure the core quality of your product — your code. Even if it seems good in the short term, in the end, you will most certainly definitely regret it.
• Even the most obvious principles are hard to follow and remember when we step into a daily coding routine. Always review them properly.
• Be glad to remove code, if it helps. Do not hang onto it just because you invested time into writing it.
• Write tests, they are at least as much important as code reviews in your process. If it’s possible, write tests.