Introduction

At most of the companies and projects there is something called four-eyes principle. That means noone is allowed to make changes totally alone, at least one more person needs to approve the changes. One popular implementation of four-eyes principle is doing code reviews. As alternative you can do pair programming. But what is a code review? How to perform it in an efficient way?

What is the goal of a code review?

Code review is one quality gate for the implemented code. The goal is that other (often more experienced) colleagues are checking the code changes, makes suggestions (so called findings) and decides if the code can be merged, or still some changes are needed?

The results of the code review needs to be documented.

The goal of code reviews is to achieve a better code quality and to share experience inside the team.

What is to be checked during a code review?

The first goal of the code review is to check for potential bugs in the code: check if the code is doing what is should, check for mistakes like usage of uninitialized variables, endless cycles, incorrect handling of memory, dead code etc.

Furthermore most projects should follow a predefined coding guideline. This guideline is up to the used programming language and it is describing how the code should look like: which missconcepts needs to be avoided, what should be the order or declarations, how to name your file, which language elements can or cannot be used, how to name your entities (functions, classes, variables, etc.), how to organize your code etc.

During the code review it should be also checked if this guideline is followed or not.

At last suggestions can be also made for the developer of the code how could it be done in a better way.

It is important that several of these points can be checked by automated code analyzer tools (dead code, naming conventions etc.), it is always a good practice to use such tools.

It is also a good practice to have a common checklist about what should be checked during the review. So that the reviewer can go through that checklist point by point to make sure to not miss anything.

It is also a good practice to make a difference between major and minor findings. Major findings are must to change and minor findings are just “would be nice to have to be changed”.

Possible ways of performing a code review

There are two main ways of performing review: do it online (face to face) or do it offline. The online version takes more time, but it has some benefits.

Online review

Performing code reviews online means that the author of the code sits together with one and more other developers. The author shows the code what he implemented and describes their implementations details and design decisions. The other developers can ask questions and make suggestions at any time.

A protocol should be created, which contains every point of the review meeting.

The big advantage of this way, that the reviewer can understand better and deeper the implementations, decisions can be clarified in a fast way and the author of the code get a detailed and direct feedback.

In case of too many findings the review meeting needs to be repeated once the findings are fixed.

Offline review

For offline review it is good to use some kind of online tool. In this case one or more developers are reviewing the code changes offline on their own at their computer and adds their findings and questions in the tool. Then the author of the code needs to answer the questions and fix the findings. It needs to be repeated again and again until the reviewer does not approve the changes. The advantages of this method are that the reviewers and the developers doesn’t need to be at the same place, they can perform the review in different time and different reviewers can review totally independently from each other. The disadvantages are that the reviewers are not going so deep into the details, in case of a lot of questions it can take long and the author of the code does not get a detailed (verbal) feedback.

Who should review the code?

It is always up to the project. In case of some projects any developer can perform a code review (usually in more agile teams). This is usually the case if the team members are on a similar level of knowledge.

In other cases the review must be performed by some domain experts, technical experts or software architects. Multiple reviewers are always welcomed. This is usually done in structures with a lot of different expert roles.

Summary

Code reviews are important quality gates. The best way of performing reviews are always up to the project needs. But anyway it should have a clear and documented process and documented results. Otherwise performing code reviews can be just a waste of time.