Code Review Guidelines
What review reliably catches, what it structurally cannot, and how to cover the difference.
Overview
This document covers what code review is good at, the two classes of defect it will not catch no matter how careful the reviewer, how to give feedback that changes an outcome, and the question worth asking about inherited code that most rubrics omit.
Why This Exists
Review is usually described only in terms of what it catches. The more useful description includes what it does not, because that is where the expensive defects live. Two designs in the systems behind this document were internally consistent, carefully reasoned, and reviewed as correct. Both were simply wrong about how something underneath them behaved. No amount of additional reviewer attention would have found either, because the mistake was not visible in the code being reviewed. Knowing that changes what you ask of review and what you build instead.
What review reliably catches
What review structurally cannot catch
Feedback that changes an outcome
The question most rubrics omit
Turnaround, and the honest version for a small team
Related Principles· 2
Related Documents· 2
Related Templates
Referenced By· 6
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Separates what review reliably catches from the two classes it structurally cannot, with the structural control for each. Adds the received-versus-decided question, feedback that changes outcomes, and an honest account of what review means without a second person.