Conducting an effective code review is an integral step in ensuring quality coding. Code review & testing are one the main things that set great engineering teams apart from mediocre ones.

Without code reviews, it’s easy to overlook bugs and aspects of the code that could be improved. To be sure your code reviews are done to a high standard and give the results needed, you will need to adhere to best practice standards in the field.

Here are five best practice points to help you make the most of your code review.

How Much Code Should be Reviewed in a Sitting?

In 2006, the SmartBear Cisco Systems code review study showed that fewer than 400 lines of code should be reviewed in one sitting. They found that between 200 and 400 lines is the optimal amount to find defects.  The brain is only able to process a certain limit of information at a time and reviewers tested at over 400 lines of code at once showed their effectiveness dropped.

Within the 200-400 lines of code limit, the yield was found to be 70-90%. There’s a point of diminishing returns, which is why teams with a dedicated code reviewer often suffer. The best review structures involve full-time programmers peer-reviewing each other a certain % of the time.

How Long Should the Review Session Take?

A review session the size of 200-400 LOC should take between 60 and 90 minutes. Having said this, you don’t want to review for more than 60 minutes in one sitting. Studies find performance rates start to drop off after 60 minutes working on one task, but taking regular breaks can help increase efficiency. If you review small quantities more often, you will reduce the need to do long reviews at any point in the future. This saves you missing defects in the code and gives a better end result.

You don’t want to rush yourself; this isn’t a race and while time is money, doing the job thoroughly is better for business in the long run than doing an average job quickly. Overall, review rates should be under 500 LOC per hour. The Cisco Systems code review study also found a significant drop in defect discovery at rates faster than 500 LOC per hour.

Set Goals

In order to get the desired outcome from a code review, you need to figure out what that desired outcome is. Deciding on a way to measure the effectiveness of code reviews gives your team a way to then determine tangible goals that can be calculated and achieved.

Effective goals are those with clear and concise information on the specific point that needs to be addressed. For example, making a goal such as “increase defect discovery by 50%” gives all the information needed to know what needs to be achieved and also gives a clear picture of how this will improve the code in the end.

A goal like “clean up code bloat” however, is not an effective goal. This gives no exact goal to be reached and therefore doesn’t give the reviewers something tangible to aim for. Even general goals like “refactoring” can be attached to certain areas of your product, or a business goal.

Set tangible metrics, so you can scale your processes.

Choosing the Right Metrics

Keeping an eye on metrics can help ensure a code review is done effectively. Important internal processing metrics to watch include:

Defect rate: the rate of errors found per hour of review time
Review rate: the speed at which a review is undertaken
Defect density: the average amount of errors found per LOC

Preparing and Submitting Feedback

When preparing feedback, keep it simple and concise. Omit any comments that aren’t necessary, as it can easily clutter the code. Give feedback on comments, code-level documentation and commit messages that will give quality information to those who will read them.

Remember to give credit where credit is due; elegant, concise and efficient code should be acknowledged and will boost the morale of the engineers when you do so. It is equally important to decline or disapprove CR when it’s redundant or irrelevant. You’re not being harsh by doing so; simply give an explanation in your feedback.

Ultimately, a good code review relies on good fundamentals. A strong review process will lift your team far more than talented programmers or fancy libraries - focus on the basics.

Making Code Review More Effective

While code review is important, not all pull requests are created equal. Make it easier for yourself to identify what code is going to make a larger impact on the code base by using a platform like Gitalytics. Gitalytics pulls Git data and deciphers it into easy to understand metrics and dashboards. Your junior engineers can focus on the small fixed, while the senior ones can tackle challenging merges.

See Gitalytics in action