Code review is a cornerstone of modern software engineering. It catches bugs before they reach production, maintains code consistency, spreads knowledge across the team, and provides a natural checkpoint for architectural decisions. Yet despite its recognized importance, many teams struggle with reviews that devolve into nitpicking, create bottlenecks, or become rubber-stamp approvals that provide little value.
Effective code review requires deliberate practice, clear expectations, and cultural norms that balance thoroughness with velocity.
What to Look for in a Code Review
Correctness
Does the code do what it claims to do? Check that edge cases are handled, error paths are covered, and the implementation matches the stated requirements. This is the minimum bar for any review, but surprisingly often overlooked when reviewers focus exclusively on style or architecture.
Pay particular attention to boundary conditions, null handling, concurrent access, and error propagation. These are the areas where bugs hide most frequently. Does the code handle the empty list case? What happens if the network call times out? Is the shared state protected against race conditions?
Design and Architecture
Does the code fit well into the existing architecture? Is the level of abstraction appropriate? Are responsibilities clearly separated? Design issues are the most valuable findings in code review because they are expensive to fix after merging and tend to compound as more code builds on top of a flawed foundation.
Look for violations of the project's established patterns. If the codebase uses repository patterns for data access, a new feature that queries the database directly introduces inconsistency. If the team has agreed on event-driven communication between modules, a new synchronous coupling may signal a design issue.
Readability
Will the next developer who reads this code understand it without asking the author? Clear naming, appropriate comments, logical organization, and manageable function lengths all contribute to readability. Code is read far more often than it is written, so optimizing for the reader's experience pays dividends over the code's lifetime.
Good names eliminate the need for most comments. A function called calculateShippingCostForOrder needs no comment explaining what it does. A variable called d needs either a better name or a comment, and a better name is always preferable.
Testing
Does the change include appropriate tests? Are the tests actually testing meaningful behavior, or are they testing implementation details that will break on refactoring? Unit tests should verify behavior, not internal method calls. Integration tests should cover the critical paths through the system.
Be skeptical of changes that modify behavior without modifying tests. Either the existing tests already cover the new behavior (verify this), the change is a pure refactoring that does not alter behavior (verify this too), or tests are missing.
Security
Security issues are among the most critical findings in code review. Check for SQL injection vulnerabilities, cross-site scripting, insecure deserialization, hardcoded secrets, insufficient input validation, and improper authentication checks. Many security vulnerabilities are obvious to a reviewer who is specifically looking for them but invisible to the author who is focused on functionality.
How to Review Code Effectively
Timebox Your Reviews
Research consistently shows that review effectiveness drops sharply after 60-90 minutes of continuous review. A reviewer examining a 2000-line change at the end of a long day will catch fewer issues than the same reviewer examining a 200-line change with fresh attention. If a change is too large to review effectively in one session, ask the author to break it into smaller, reviewable chunks.
Review in Multiple Passes
Rather than trying to catch everything in a single reading, make deliberate passes focused on different concerns. First, read through for high-level understanding of what the change does and why. Then review for correctness and edge cases. Then check for style, naming, and readability. Multiple focused passes catch more issues than a single unfocused pass.
Use the Checklist, Then Go Beyond It
Many teams maintain review checklists covering common issues: error handling, logging, test coverage, documentation updates. Checklists prevent experienced reviewers from missing routine items and help junior reviewers know what to look for. However, checklists cannot cover everything. The most valuable review comments often address issues specific to the particular change, like a subtle logic error or an architectural concern that no generic checklist would catch.
Run the Code
Reading code statically catches many issues, but running the code catches different ones. Check out the branch, exercise the feature manually, and verify that it works as described. This takes more time than a desk review but catches issues that are difficult to spot in a diff view, particularly around UI changes, configuration, and integration behavior.
How to Give Review Feedback
Distinguish Between Blocking and Non-Blocking Comments
Not all review comments are equally important. Clearly distinguish between issues that must be fixed before merging (bugs, security issues, design problems) and suggestions that are optional improvements (alternative approaches, minor style preferences, nitpicks). Many teams use prefixes like nit: for non-blocking suggestions or blocking: for required changes.
Explain Why, Not Just What
A comment saying "this should use a map instead of a list" is less helpful than "using a map here would improve lookup performance from O(n) to O(1), which matters because this function is called in a loop processing thousands of items." The explanation helps the author understand the reasoning, learn from the feedback, and make better decisions independently in the future.
Offer Solutions, Not Just Problems
Pointing out that a function is too complex without suggesting how to simplify it puts the burden entirely on the author. When possible, include a suggestion for how to address the issue. This does not mean writing the code for the author, but a brief sketch of an alternative approach demonstrates that the concern is actionable rather than just critical.
Keep the Tone Constructive
Code review is a conversation between colleagues, not a judgment of competence. Frame feedback as questions or suggestions rather than commands. "Have you considered handling the timeout case here?" is more collaborative than "You forgot to handle timeouts." The goal is to improve the code together, not to demonstrate the reviewer's superiority.
How to Receive Review Feedback
The author's response to feedback is equally important to the review's effectiveness.
- Assume good intent. Reviewers are trying to improve the code and help you grow, even when comments feel critical.
- Respond to every comment. Even if the response is "done" or "good point, fixed." Unacknowledged comments create ambiguity about whether the feedback was addressed.
- Push back thoughtfully. If you disagree with feedback, explain your reasoning. "I considered that approach but chose this one because..." leads to productive discussion. Silently ignoring feedback or dismissing it without explanation undermines the review process.
- Separate ego from code. The code is not you. Criticism of the code is not criticism of your abilities. This distinction is difficult but essential for participating in honest code review.
Systemic Practices for Better Reviews
- Keep changes small: Target 200-400 lines per review. Smaller changes get faster, more thorough reviews with higher quality feedback.
- Write good PR descriptions: Explain what changed, why it changed, and how to test it. Context dramatically improves review quality.
- Set SLA expectations: Agree on how quickly reviews should happen (e.g., within 4 business hours). Stale PRs demoralize authors and increase merge conflicts.
- Rotate reviewers: Avoid concentrating all review work on senior developers. Rotating reviewers spreads knowledge and develops review skills across the team.
- Automate the automatable: Formatting, linting, and style checks should be enforced by tools, not humans. Human attention is too valuable to spend on brace placement.
Code review is both a technical practice and a social one. Teams that invest in building a healthy review culture, one that is thorough without being slow, critical without being hostile, and consistent without being rigid, see compounding returns in code quality, team knowledge, and developer satisfaction.
