code-review-excellence

Constructive code review feedback is specific, actionable, and focused on the code rather than the person. Use questions instead of commands, label comments by severity such as blocking or nit, and pair criticism with a suggested solution or example.

Check logic correctness, edge cases, security vulnerabilities, performance issues, test coverage, error handling, and naming clarity. Skip formatting and linting concerns, which should be handled by automated tools like linters and formatters.

A typical review follows four phases totaling roughly 20 to 35 minutes: context gathering, high-level design review, line-by-line analysis, and summary. Limit review sessions to 60 minutes and keep pull requests under 400 lines for effective review.

Common Python issues include mutable default arguments, overly broad except clauses, and mutable class attributes shared across instances. Reviewers should verify functions use None defaults, catch specific exceptions, and initialize instance state in __init__.

Handle disagreements by seeking to understand the author's reasoning, acknowledging valid points, and requesting data such as benchmarks to validate concerns. Escalate to a senior engineer if unresolved, and approve non-critical differences rather than blocking progress.