How to do code reviews
You have just been assigned to review the code your team wrote. This sounds like a challenge. Here are some quite reasonable questions you might have: What do I have to do ? What am I looking for ? Am I doing this thing right ? I’m going to try to answer these questions in the following article.
Table of Contents
What do I have to do?
There are many purposes for code reviews. Arguably, the main purpose of code reviews is to keep bugs from causing problems to real users. Additionally, if you’re doing a code review, you should check that all the intended spec is actually implemented. Try to think of the corner cases: are they all covered or is there something missing from the code. A good giveaway for this are conditional statements. Look out for if / switch instructions.
We use code reviews for another, more subtle, reason: consistency. As part of the review process, you should flag code snippets that do not adhere to the project coding styling. This way we manage to keep fairly large project consistent.
What am I looking for ?
This is a broad question. There could be missing pieces, bits that should be replaced and snippets that should be removed completely. Try to think about whose code you are reviewing and that should give you a hint about what you are looking for. A couple of examples here to drive the point home: If the developer fairly inexperienced, I look for omissions on the spec and corner cases. If they are new on the project, I look at the coding style and general patterns. If the code deals with asynchronous operations, I look for deadlocks and race conditions. Transaction isolation levels are another point that needs special attention when reviewing concurrent code.
Am I doing this right?
Now that we know what we’re looking for, here are some guidelines to make the whole experience nicer:
Give explanations: When you are reviewing code, you are not only preventing problems, you are also helping the developer improve their skills. A fantastic way to do this is to always explain the reasons for your suggestions. This way, one of two things happen: either the developer agrees with the reasoning, and they are going to apply the same reasoning in the future, thus preventing future issues from popping up, or they can start a discussion and an agreement will eventually be reached.
Give praise when praise is due: A little encouraging can go a long way. Be on the lookout for praise-worthy code snippets and recognize them. I guess this should go without saying, but don’t be mean. Someone worked hard for that code snippet, even if it does not look like it, so be respectful when commenting.
Don’t overdo it: Doing code reviews is hard work. It requires quite a lot of mental energy and concentration. Best practices suggest you should do no more than 60 minutes of code reviewing at a time. Also, try to keep reviews under 400 lines of code.
It may seem like you are not doing much work: I find code reviews quite an interesting activity. And by interesting, I mean it does not produce any tangible results and is quite hard to get KPI’s on it. Because of that, you might find yourself thinking you are not doing any actual work. That is not the case. Code reviews are an important part of ensuring code quality, so don’t beat yourself up.