Peer Review

Many organizations that produce software utilize code reviews to help mantain a high quality code base. Our peer review process is not exactly code review – your reviewers are not “approving” your solution. However, my hope is that the peer review process will achieve similar ends: improving the quality of your solutions and allowing you to learn from one another.

A good code review should address the following questions:

  1. Does the code work? Does it do what it is supposed to?
  2. How is the style of the code? Does it follow the style guidelines?
  3. Is the code clearly structured and easy to understand?
  4. Is the code efficient? If clarity is sacrificed for efficiency, do the comments help alleviate this?

In addition, a good code review is kind to the author. Comments are framed as suggestions to the author and written in a positive, respectful, tone. Comments address the good qualities of the code as well as any areas for improvement.

Finally, a good code review begins with the most essential aspects related to the four questions above. More minor items – called ‘nitpicks’ – are clearly labeled as such and kept to a minimum.

Guidelines

Review each question separately. This can be in a single comment, but finish reviewing each question before moving on to the next.

Address each of the four questions above in your review. If there are no specific items to draw attention to, simply say something positive.

If you have nitpicks, put them in a section labeled “nitpicks” at the end of (that question’s) review.

Be positive and respectful. Disrespectful reviews may result in deductions to your own assignment.

You are not expected to fully test or check the code being reviewed. You should spend between 5 and 15 minutes reviewing each question and writing your review.

Reading