4 Rules of Thumb for Providing Effective Code Review Feedback

image by Manu Cornet under Creative Commons license

The worst case scenario for a peer code review is when each developer thinks the other will look at the code closely. This happens in real life, more often than you would think. How do you go about ensuring this does not occur? A large part is establishing a healthy code review culture, where the roles and expectations of the parties are known.

For the purpose of this article I am going to focus on the role of the person reviewing the code. Here are 4 rules of thumb to start establishing a healthy code review process:

Rule #1: Let people know right away, if you are the wrong code reviewer.

There is nothing worse than waiting for a review only to find out you sent it to the wrong person and have to start waiting all over again. In addition, if you are not the right person, provide guidance on who may be, if you can.

If you are the right reviewer, do a preliminary check using the following rules:

Rule #2: The review is not more than X lines of code.

Most team have an established a norm for the number of lines that is reasonable, based on the coding language and the nature of the code. There may be a valid reason for the large review (i.e. it is porting a library, it can’t be isolated till all of the changes are…