Code Reviews

Best practices code reviews

• Review fewer than 200-400 lines of code at a time - For optimal effectiveness, developers should review fewer than 200-400 lines of code (loc) at a time.
• Aim for an inspection rate of fewer than 300-500 lines of code per hour - Take your time with code review. Research has shown that you will achieve optimal results at an inspection rate of less than 300-500 lines of code per hour.
• Never review code for more than 90 minutes at a stretch - After about 60 minutes reviewers simply get tired and stop finding additional defects. It’s generally known that when people engage in any activity requiring concentrated effort, performance starts dropping off after 60-90 minutes. Given these human limitations, a reviewe will probably not be able to review more than 300-600 lines of code before performance drop. On the flip side, you should always spend at least 5 minutes reviewing code, even if it’s just one line. Often, a single line can have consequences throughout the system, and it’s worth the five minutes to think through the possible effects that a change could have.
• Have authors annotate source code before the review begins - Annotations guide the reviewers through the changes, showing which files to look at first and defending the reason and methods for each code modification. These notes are not comments in the code, but rather comments given to other reviewers. By annotating the source code the developer is required to double-check his work which will uncover many of the defects before the review even begins.
• Establish quantifiable goals for code reviews, and capture metrics so you can improve your process - When you have defined specific goals, you will be able to judge whether peer review is truly achieving the results that you require. It’s best to start with external metrics such as “reduce support calls by 20%”, or “halve the percentage of defects injected by development”. However, it can take a while before external metrics show results.
• Use checklists - Checklists are a highly recommended way to check for the things that you might forget to do. Omissions are the hardest defects to find. as soon as you start recording your defects in a checklist, you will start making fewer of these errors.
• Verify that the defects are actually fixed - Many teams that review code don’t have a good way of tracking defects found during review and ensuring that bugs are actually fixed before the review is complete.
• Foster a good review culture in which finding defects is viewed positively - It’s easy to see defects as a bad thing, but fostering a negative attitude toward defects found can sour a whole team. It must be promoted that defects are positive. After all, each one is an opportunity to improve the code, and the goal of the code review process is to make the code as good as possible. Every defect found and fixed in peer review is a defect that a customer never sees and another problem QA doesn’t have to spend time tracking down. Reviews present opportunities for all developers to correct bad habits, learn new tricks, and expand their capabilities.
• Beware of the big brother effect - Metrics are vital for process measurement, which form the basis for process improvement. If developers believe that metrics will be used against them, not only will they ber hostile to the process, but they will probably focus on improving their metrics rather than truly writing better code and being more productive.
• Review at least part of the code to benefit from the ego effect - The ego effect drives developers to write better code because they know that others will be looking at their code and metrics. No one wants to be known as the guy who makes all those mistakes. The ego effect drives developers to review their own work carefully before passing it on to others.