# Code review Code review is the practice of developers other than the author reading a change, commenting on it, and approving or blocking it before it lands. The form ranges from Fagan's heavyweight inspection (Fagan 1976)[^fagan1976] to modern pull-request review at Google and Microsoft. ## What it catches The measured value of modern code review is mostly *not* defect detection (Bacchelli and Bird 2013)[^bacchelli2013]. It is: - **Knowledge transfer.** Participating in review raises a reviewer's exposure to distinct files by 66–150% (Rigby and Bird 2013)[^rigby2013]. - **Alternative solution generation.** A reviewer proposes the simpler approach. - **Gatekeeping for codebase health.** Style, naming, hygiene consistency without needing every author to internalize every rule. The defects review does catch are usually *high-level* ones — wrong abstraction, missing edge case, inconsistency with other parts of the codebase — that automated checkers miss. Code review does **not** systematically catch the bugs [example tests](https://quality.stereobooster.com/example-tests.md) miss — both rely on what the reader (reviewer or test author) has thought of. ## Tools and form Modern code review is **tool-based, lightweight, continuous**. Tools: - **Forge-native.** GitHub pull requests, GitLab merge requests, Bitbucket pull requests, Gerrit (Google-style). - **CI integration.** Linter, formatter, type checker, security scanner all reporting inline at diff time. Diff-time deployment beats batch (Distefano et al. 2019)[^distefano2019], 70% fix rate vs ~zero. - **AI-assisted review.** Claude's code-review skill, Cursor, [Open Code Review](https://github.com/alibaba/open-code-review), and similar agents. These extend human reviewers rather than replace them. [Code Review Bench](https://github.com/withmartian/code-review-benchmark) scores precision (share of comments that flag a real issue) and recall (share of real issues caught) on human-verified pull requests, with a continuously-refreshed online set to keep tools from memorizing the cases. ## When to use, when not **Applies to every change.** For knowledge spread, codebase health, and the kind of high-level defect that automated tools miss. **Not a primary defect filter.** The strongest defect filters are types, [static analysis](https://quality.stereobooster.com/static-analysis.md), fuzzing, property-based testing, and tests. **Does not benefit from scaling up.** More reviewers, longer reviews, bigger diffs all reduce effectiveness. ## Evidence - **Modern review is mostly knowledge transfer.** At Microsoft, only a minority of review comments were defect-related — a smaller share of review value than practitioners expect (Bacchelli and Bird 2013)[^bacchelli2013]. - **Convergent practice across organizations.** A multi-site study (Microsoft, Google, AMD, Lucent, 6 OSS projects) found the same shape everywhere: small diffs, 1–2 reviewers, fast turnaround, diminishing returns past 2 reviewers (Rigby and Bird 2013)[^rigby2013]. - **Google scale.** Over ~9M reviewed changes, median 1 reviewer, 70% merged within 24h (Sadowski et al. 2018)[^sadowski2018]. - **Defect-finding drops past ~90 min of review, and when the review rate exceeds ~400–500 LOC/hour**, in a Cisco/SmartBear study (Cohen 2006)[^cohen2006]; vendor-published — treat as directionally suggestive. ## Classification - **Quality dimensions:** Maintainability, Functionality. - **Area:** General development; any codebase that goes through pull requests or change reviews. ## Referenced by - [Maintainability](https://quality.stereobooster.com/maintainability.md) · Quality dimensions - [Quality dimensions](https://quality.stereobooster.com/quality-dimensions.md) · Quality dimensions - [Effect scope](https://quality.stereobooster.com/effect.md) · The axes - [Oracle](https://quality.stereobooster.com/oracle.md) · The axes - [Refactoring practice](https://quality.stereobooster.com/refactoring-practice.md) · Methods - [Static analysis](https://quality.stereobooster.com/static-analysis.md) · Methods - [Verifying numerical code](https://quality.stereobooster.com/numbers.md) · Methods - [AI tooling for process methods](https://quality.stereobooster.com/ai-process.md) · AI - [How AI fits into software quality](https://quality.stereobooster.com/ai.md) · AI ## References [^fagan1976]: Fagan, Michael E. 1976. "[Design and Code Inspections to Reduce Errors in Program Development](https://www.ida.liu.se/~TDDC90/labs/lab-papers/fagan76.pdf)." *IBM Systems Journal* 15 (3): 182–211. . [^bacchelli2013]: Bacchelli, Alberto, and Christian Bird. 2013. "[Expectations, Outcomes, and Challenges of Modern Code Review](https://sback.it/publications/icse2013.pdf)." *Proceedings of the 35th International Conference on Software Engineering (ICSE '13)*, 712–21. . [^rigby2013]: Rigby, Peter C., and Christian Bird. 2013. "[Convergent Contemporary Software Peer Review Practices](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/rigby2013convergent.pdf)." *Proceedings of the 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE '13)*, 202–12. . [^distefano2019]: Distefano, Dino, Manuel Fähndrich, Francesco Logozzo, and Peter W. O'Hearn. 2019. "[Scaling Static Analyses at Facebook](https://cseweb.ucsd.edu/~dstefan/cse227-spring20/papers/distefano:scaling.pdf)." *Communications of the ACM* 62 (8): 62–70. . [^sadowski2018]: Sadowski, Caitlin, Emma Söderberg, Luke Church, Michal Sipko, and Alberto Bacchelli. 2018. "[Modern Code Review: A Case Study at Google](https://sback.it/publications/icse2018seip.pdf)." *Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '18)*, 181–90. . [^cohen2006]: Cohen, Jason. 2006. *[Best Kept Secrets of Peer Code Review](http://borg.csueastbay.edu/~grewe/CS401/Mat/SWManagement/CodeReview/best-kept-secrets-of-peer-code-review_redirected.pdf)*. SmartBear Software. [http://borg.csueastbay.edu/\~grewe/CS401/Mat/SWManagement/CodeReview/best-kept-secrets-of-peer-code-review\\\_redirected.pdf](http://borg.csueastbay.edu/~grewe/CS401/Mat/SWManagement/CodeReview/best-kept-secrets-of-peer-code-review\_redirected.pdf). ## Acronyms - LOC — lines of code - OSS — open-source software