Skip to content


Code reviews

Tended 3 months ago (1 time) Planted 8 months ago Mentioned 0 times

Table of Contents

Code reviews are a form of peer feedback for programmers.

Insights from a study by SmartBear of a Cisco programming team:

  • Keep change sets small: beyond 400 lines of code, developers’ ability to find defects diminishes. Review effectiveness increases as change set size decreases, so the smaller the better!

    a chart mapping defects found against change set size shows them inversely related

  • Don’t review for more than an hour at a time: as with most cognitively-demanding tasks, effectiveness diminishes over time as the brain tires.

  • Authors should annotate change sets for reviewers, which allows reviewers to be more focused and effective

  • Review at least 33% of change sets to trigger what the study calls “the ego effect”: “The knowledge that others will be examining their work naturally drives people to produce a better product.”

Gunnar Morling suggests a hierarchy of different kinds of feedback he calls “The Code Review Pyramid”. For example, feedback on API design is more fundamental than feedback on style. Reviewers should spend more time on the more important kinds of feedback, ideally by automating the less-important kinds of feedback such as with linters and formatters. I would add that the more fundamental feedback is best given earlier (so you don’t waste time on the syntax of semantically-inappropriate code) so it’s best to ask for early feedback on new APIs before a final code review.

Gunnar Morling's code review pyramid, showing kinds of feedback in order of importance: API semantics, implementation semantics, documentation, tests, and code style