Code Review Checklist Template

Correctness

• The code does what the PR description says it does

• Edge cases are handled (null/empty inputs, boundary values, concurrent access)

• Error handling is appropriate (errors are caught, logged, and surfaced correctly)

• All new code paths have corresponding tests

• Existing tests still pass and are not broken or silently skipped

• No regressions in existing functionality

• Database migrations are reversible and safe for zero-downtime deployment

• State mutations are correct (no stale data, race conditions, or lost updates)

Security

• No secrets, API keys, or credentials committed (check for hardcoded values)

• User input is validated and sanitized before processing

• Authentication and authorization are enforced on new endpoints

• No SQL injection, XSS, or CSRF vulnerabilities introduced

• Sensitive data is not logged or exposed in error messages

• Dependencies are from trusted sources and free of known vulnerabilities

• File uploads are validated (type, size, content)

• Rate limiting is considered for new public-facing endpoints

Performance

• No N+1 query patterns (check for loops that issue database queries)

• Database queries use appropriate indexes (check query plans for new queries)

• No unnecessary memory allocations or data copying

• Caching is used where appropriate and cache invalidation is correct

• Pagination is implemented for list endpoints that could return large datasets

• No blocking operations on the main thread or hot paths

• Bulk operations are used instead of row-by-row processing where applicable

Maintainability

• Code is readable without requiring extensive comments to understand

• Variables, functions, and classes have clear, descriptive names

• No unnecessary duplication (DRY principle applied appropriately)

• Abstractions are at the right level (not over-engineered, not under-abstracted)

• Non-obvious design decisions are documented with comments explaining why

• Magic numbers and strings are replaced with named constants

• Functions have a single, clear responsibility

• Complex logic is broken into well-named helper functions

Testing

• Unit tests cover the happy path and key error paths

• Integration tests are added for complex interactions (database, external services)

• Edge cases are tested (empty inputs, max values, concurrent operations)

• Test names clearly describe what is being tested and expected behavior

• Tests are independent and do not rely on execution order

• Test data is generated or built with factories (no fragile hardcoded fixtures)

• Mocks and stubs are used appropriately (not over-mocking)

API Design

• API changes are backward compatible (or breaking changes are intentional and documented)

• HTTP methods are used correctly (GET for reads, POST for creates, etc.)

• Naming is consistent with existing API conventions

• Request/response schemas are validated

• Error responses include meaningful error codes and messages

• API documentation is updated to reflect changes

Overall Assessment

Verdict

• Approve — Changes are correct, well-tested, and ready to merge

• Request changes — Issues must be addressed before merging

• Comment — Non-blocking feedback, approve at author's discretion

Summary

Write a brief summary of your review. Highlight what the author did well and what needs attention. Be specific and constructive.

Comments / Feedback

List specific feedback items with file and line references:

1. [file:line] — Describe the feedback or concern

2. [file:line] — Describe the feedback or concern

3. [file:line] — Describe the feedback or concern