Code Review — Cheat Sheet

Tags: code-review, git, pull-request, clean-code, testing, devops, collaboration

Level: intermediate

TL;DR: Best practices, checklist items, and conversational tactics for conducting thorough, constructive, and efficient pull request reviews.

Key concepts

Reviews verify correctness, security, architectural consistency, and maintainability before merging.

Keep pull requests small and focused, ideally under 400 lines of code.

Automated linters, formatters, and CI pipelines handle style; humans review design and logic.

Differentiate blocking architectural defects from non-blocking suggestions using conventional comment prefixes.

Validate test coverage by checking happy paths, edge cases, error states, and regressions.

Verify security aspects including input validation, authorization checks, and secret leakage.

Confirm backward compatibility for database schemas, public APIs, and configuration changes.

Frame comments constructively by discussing code artifacts rather than the developer personally.

Approve or request changes promptly to maintain continuous team delivery cadence.

Typical questions and ready answers

Q: What is your approach when reviewing a large pull request?R: I start by understanding the linked issue, requirements, and design context before inspecting individual lines. Then I examine tests and interface contracts first to verify intent, leaving smaller implementation details and non-blocking nits for last.

Q: How do you handle disagreement with another engineer during a review?R: I anchor arguments to concrete trade-offs, documentation, or team conventions rather than personal preference. If asynchronous discussion exceeds two back-and-forth cycles, I schedule a quick 5-minute call to align and document the agreed decision on the PR.

Q: What tools do you rely on to keep code reviews effective?R: I rely on automated CI gates for linting, unit tests, and security scanning so human review focuses on architecture and business logic. I also use conventional review tags like "nit:" or "suggestion:" to clarify priority immediately.

Pitfalls and common mistakes

Nitpicking formatting or styling manually instead of enforcing automated linter and formatter rules.

Reviewing implementation details while missing flawed business requirements or architectural mismatch.

Approving massive PRs cursorily due to review fatigue (the LGTM stampede).

Leaving ambiguous comments without explaining the underlying risk or providing actionable alternatives.

Coupling unrelated refactorings or dependency updates into a critical bugfix pull request.

Delaying PR feedback for multiple days, causing merge conflicts and blocking release trains.

Snippets and commands

# View summary of changed files with diff stats
git diff --stat origin/main...HEAD

# Review commit history cleanly without merge commits
git log --oneline --no-merges origin/main..HEAD

# Inspect word-level changes in a specific commit
git diff --word-diff HEAD~1 HEAD

Markdown

<!-- Conventional comment examples -->
nit: Extract this calculation into a pure helper function for readability.
issue (blocking): Missing authorization check before updating entity status.
question: What happens if the external payment webhook returns a 504 timeout?
suggestion: Consider using Set lookups here to avoid O(N^2) complexity in this loop.

To review

[ ] Conventional Comments specification (nit, suggestion, blocking)

[ ] OWASP code review checklist for authentication and data injection

[ ] Git patch inspection flags and local review workflows

[ ] Team SLA conventions for PR turnaround times

References

Google Engineering Practices documentation: How to do a code review

Conventional Comments standard (conventionalcomments.org)

SmartBear: Best Practices for Peer Code Review