Code Review #

This document describes what to look for when reviewing changes.

Review Checklist #

Correctness #

• Logic errors, off-by-one mistakes, unhandled edge cases
• Does the code do what it claims?
• Are error conditions handled?

Safety #

• Resource leaks (file handles, connections, memory)
• Injection risks (SQL, command, template)
• Improper input handling or missing validation at system boundaries

Error Handling #

• Errors are surfaced clearly, not silently swallowed
• Error messages are actionable and include context
• Failures don't leave the system in an inconsistent state

Style #

• Follows conventions from the Code Style Guide
• Naming is clear and consistent with the codebase
• Code organization matches project structure

Documentation #

• Public APIs and non-obvious logic are documented
• Comments explain why, not what

Test Coverage #

• New functionality has corresponding tests (see the Testing Guide)
• Edge cases are tested
• Existing tests are not weakened or removed without justification

Dependency Hygiene #

• No unnecessary new dependencies introduced
• Dependencies are up to date and maintained
• Transitive dependency impact is considered

Severity Levels #

Findings should be categorized by severity:

• Blocking – must be fixed before merge (bugs, correctness issues, test failures, security vulnerabilities)
• Warning – should be fixed but not a showstopper (style violations, missing tests for edge cases)
• Suggestion – optional improvements (refactoring ideas, alternative approaches, documentation improvements)