Learning from Code Reviews

The last couple of weeks I have been actively involved in writing a code review for the project I’m currently working on. As this was my first real code review, I spend time finding resources on the subject. First off, there isn’t a lot of great articles about this subject. Secondly, most of them focus on the code review itself, what to notice, write down etc.

In this blog I want to address the other side of the medal, namely a code review viewed as a developer. Code reviews are for the developers. So it’s important that you, as a developer, understand what is in the review and learn from it.

Why code review matter

Code review are a way to keep the quality of the code at a high. Finding bugs are the second most important thing a code review can accomplish. The most important benefit is when done right, a code review will deal with bugs before they are even written. By enforcing best practices (e.g. design patterns) and principles (Single Responsibility Principle, Liskov Substitution Principle, …) and also coding guidelines such as commenting every method, using describing method names, bugs will actually be avoided because the quality of the code is augmented!

It’s important for you, a developer, to realise that code reviews aren’t for discussing your bad code. See it more are an effort to increase the level of quality in the entire code.

The Cheat Sheet

One nice tip I came across is the use of a cheat sheet. At the start of the code review, all developers should bring a piece of paper. When discussing the review, each developer should write down an issue he/she would be able to write. As a developer, don’t focus on only the code you wrote, but ask yourself the following questions:

• Could I have made the same mistake?
• Did I know about the item, why is was wrong?
• Would I have noticed the code myself?

If you answered yes to any of these question, you should write down the issue on your cheat sheet.

The cheat sheet should be used every time you want to commit code. Take the cheat sheet (really read it) and check the code if something could be coded better. Having the cheat sheet will help you to not introduce items already covered by a code review. Reviewing the same bad code twice is a sign a developer hasn’t learned from the previous review.

Create a positive environment

When reviewing code it’s important to create a surrounding where it’s encouraged to discuss code, where it is a positive thing when code can be improved rather then pick on the one who wrote less then perfect code. As a developer you should keep this in mind as well. Nobody wants to write bad code, so don’t focus on the coder, focus on the code!

Don’t be afraid to discuss code. Sometimes it’s only after a couple of questions that code is really well understood. Sometimes reasons for particular code goes deeper then eyes at first see. A successful code review is a review where developers asked question about code.

Beware of the developer against the world syndrome. It’s normal to take pride on your code. Don’t let the pride come between your code and better code. It’s a learning experience, embrace it and swallow the pride when necessary. That one of the reasons code review are a group thing.

Refrain from negative comments or inappropriate comments. A good example is saying: I would never write that; Who wrote THIS? etc.

Semper paratus

Always be prepared. A great developer will have read the copy before entering the discussion, making the review go faster and the questions more intelligent. It’s just common sense to at least spend a few minutes preparing for any meeting, even internal code reviews.

Anyway, this blog is shorter then I would like. Although code reviews are really important, no matter what kind of project, learning from them is even more important. Take the review serious and you will be rewarded with some extra experience!

Feel free to post any comments about this blog.

Andries