code-review-checklist

title	code-review-checklist
name	code-review-checklist
description	Review code against a standard checklist covering security, correctness, performance, and readability. Use when asked to review code, check a PR, or audit changes.

Instructions

Work through each category in the checklist below. For each item, either confirm it passes or flag the specific file and line number where the issue appears.

1. Security

• Hardcoded secrets: check for API keys, passwords, tokens, or credentials embedded in the code
• Input validation: confirm that inputs from external sources (user input, API responses, file contents) are validated before use
• SQL injection: check that any database queries use parameterized statements or an ORM, never raw string concatenation with user input
• Authentication and authorization: if the code touches access control, verify that checks happen server-side and cannot be bypassed by the caller

2. Correctness

• Edge cases: null values, empty collections, zero, negative numbers, empty strings — does the code handle these?
• Error paths: are errors caught at the right level? Are they handled or propagated with enough context to debug?
• Off-by-one: check loop bounds and index arithmetic
• Concurrency: if the code runs in a concurrent environment, check for shared mutable state without proper synchronization

3. Performance

• N+1 queries: check for database queries inside loops
• Unnecessary work: repeated computation of the same value, re-fetching data that was already fetched
• Memory: large allocations inside tight loops, unbounded collections that grow with input size

4. Readability

• Naming: variables, functions, and classes should communicate intent without needing a comment
• Comments: comments should explain why, not what. Flag comments that describe what the code does (the code shows that already) and missing comments where the intent is non-obvious
• Function length: flag functions that do more than one thing or that span more than roughly 40 lines without a clear reason
• Magic numbers: unexplained numeric or string literals that should be named constants

5. Tests

• Happy path coverage: does the test suite exercise the main success case?
• Edge case coverage: are the edge cases identified in the Correctness section tested?
• Test clarity: do test names describe the behavior being tested, not the implementation?
• Mocks and stubs: are external dependencies properly isolated in unit tests?

Output format

Group findings by category. Under each category heading, list specific issues with file name and line number where applicable. If a category has no findings, write "No issues found." at the end of each category.

If the code passes all checks, say so clearly after listing the categories.