This is the third and last part of my code review related blog post series. Previous posts have been about benefits of code reviews and code review best practices for authors. This time I have written best practices for reviewers.
“I Don’t Have Time to Review”
I guess everyone who has worked with code reviews have faced this problem one way or another. As an author, you’ve been waiting many days for the reviewer to review your code (remember my hint in the previous blog post: short reviews). On the other hand, you have had pressure to do your own work and haven’t had time to review.
Do The Review On Breaks
Code reviews aren’t critical priority work where you have to stop any other work and do review immediately. Neither they are minor priority work that you can postpone days.
My hint is to do reviews on breaks that you have during a workday:
- Very first in the morning,
- When you have finished another task before switching to a new task,
- After meeting, lunch or coffee break before starting or continuing another task or
- As the last task before leaving.
These are the breaks that each of us has few times in a workday. On these breaks check is there any review waiting for you and do the review immediately. If the author has followed best practices for authors (“keep it short!”), it will usually take 15-30 minutes to review the code.
My advice is to do the review within four working hours after you have received it. You have 2-3 breaks during that time slot and the author doesn’t have to wait too much for a review.
Things to Review
What should I review? My advice is simple: review what you think is important. That is something you are good at and you can teach it to others.
Remember that you don’t have to fully understand everything that you review. If you don’t understand something try to learn even little about it. Or ask the author about it and he will tell more about it. The author might even find something to improve, to make it easier to understand.
Keep an eye on the things that static code analyzers can’t do. One of the best is namings. Static code analyzers can validate is naming syntax correct but they can’t validate the meaning. Can you understand class, variable, method etc. names easily? Is name good enough name for a variable or should it be firstName? Namings are one of the most important things when making readable code. This is a really effective way to review the code and make it better.
If you know something about the code earlier, look at code’s design and architecture. Is there something that could stop development in the future? Has the author missed some existing class or method? Is there duplicate code blocks? These are more difficult to review than namings but can be crucial.
Be Polite!
When commenting on code review remember to be friendly and criticize the code, not the author. For example, “wtf”s shouldn’t ever be commented. That doesn’t mean you can’t criticize the code. Remember that the author wants you to criticize if there is a reason for it. But you can do that in a friendly way. “Wtf”s will surely worsen team spirit.
While it’s easy to see defects as purely negative, each bug is actually an opportunity for the team to improve code quality. (smartbear.com)
Don’t Comment Too Much
This hint is especially for me. I have a bad habit to comment a lot. When you comment much there is a risk that most of the comments will be ignored. If you write only a few comments, those comments are more powerful because they will be certainly read. My suggestion is to write max 10 comments per code review.
You might think “but what if there are more than 10 issues that I have to comment?”. In that case, put comments to 10 most critical places. If code review is short, as I suggested in the previous blog post, there shouldn’t be more than 10 major issues. (If there really is more than 10 bugs, then you should comment all of those.)
Conclusion
Reviewing code is an important task where you can give feedback to the programmer and sometimes learn from him. If you do it right, the programmer can learn something and code quality will be better. In this blog post, I wrote a few hints to better review the code. I selected hints that I think are most important and I have experienced that have improved code review quality and efficiency.
Here is the summary of best practices for the reviewers:
- Do the reviews on breaks,
- Review what you think is important,
- Keep an eye on the namings,
- Be polite and
- Don’t comment too much.
Lassi Autio's Software Development Blog 
2 thoughts on “Code Review Best Practices For Reviewers (Code Review 3/3)”