Why do programmers check each other's code before it ships?
Most of what reviewers say is not about bugs at all, but about whether the next person will understand the code.
โถ Start the storyProgrammers check each other's code because a second reader catches problems the author did not, and learns the code along the way. In a code review, at least one person who is not the author reads the change before it joins the shared project. They look for mistakes, but also for anything confusing. Only after someone else has understood and accepted the change does it ship.
The reasons go beyond catching bugs. A review can find problems in correctness, speed and security, and even code that was planted on purpose to cause harm. It also spreads knowledge: learn how the codebase works, and authors learn what the team expects. In some fields review is required by rule, such as in air traffic software and other safety-critical systems.
Reviews started as a heavy ritual. The first process that researchers described in detail was called Inspection by its inventor, Michael Fagan, and in formal versions people meet to examine code line by line, sometimes on printed copies. Most teams now use something lighter: each small change, such as a ticket or a , is read by a colleague before it is merged. Microsoft, Google and Facebook are known to work this way.
The surprise is what actually talk about. Studies suggest that up to 75% of review comments are about whether code will be easy to , and less than 15% of issues relate directly to bugs. A review is as much a conversation between people as an inspection of code.
< 15%
Quiz me
0/3
Recap
Code review puts a second human between a change and the shared code, mainly to keep the code understandable and correct.
๐ก A trick to remember it ยท The author sees what they meant; the reviewer sees what is written.
Surprising fact ยท Under 15% of issues raised in reviews relate directly to bugs.
Sources (1)
No source, no claim. Every fact in this lesson (15 claims) cites at least one of these.