What are the best practices for code reviews

· Category: Tech Career

Short answer

Good code reviews are timely (within 4 hours), focused (on logic and design, not style), and constructive (suggest alternatives, not just point out problems). Reviewers should check for correctness, readability, edge cases, and test coverage. Authors should keep PRs small, write clear descriptions, and self-review before requesting others. For related team practices, see how to effectively use Git in a team environment.

What to review

  1. Correctness: Does the code do what it claims? Are there off-by-one errors?
  2. Edge cases: What happens with empty input? Null values? Concurrent access?
  3. Readability: Can a new team member understand this code in 6 months?
  4. Testing: Are there unit tests? Do they cover the important paths?
  5. Performance: Is there an N+1 query? Unnecessary re-renders?
  6. Security: SQL injection? XSS? Missing auth checks?

What NOT to review

  • Style: That's what linters and formatters are for. Configure Prettier and ESLint, then stop debating tabs vs spaces
  • Minor naming: Only flag truly confusing names, not personal preference differences
  • Trivial changes: Auto-approve typo fixes and documentation updates

Tips for authors

  • Keep PRs under 400 lines — large PRs get skimmed, not reviewed
  • Write a PR description that explains WHY, not just WHAT
  • Self-review your diff before requesting review — catch your own mistakes first

Tips for reviewers

  • Ask questions instead of making demands: "What happens if the list is empty?" vs "You forgot to handle empty lists"
  • For Git workflow context, see how to resolve Git merge conflicts