Academy
easyEngineering Practices#86

Code review checklist

Prompt

Create a code review checklist as a comment block covering: functionality, performance, security, testing, and style for a React Native PR.

Solution

/*
 * Code Review Checklist
 *
 * 1. Functionality: Does the code solve the problem? Edge cases: empty states, offline, slow network?
 * 2. Performance: Unnecessary re-renders? List virtualization? Heavy computations memoized? Measured, not guessed?
 * 3. Security: User input validated? Tokens in Keychain/Keystore, not AsyncStorage? Deep link params sanitized? No secrets in the diff?
 * 4. Testing: Unit tests for logic? Component tests assert behavior, not internals? Error states covered?
 * 5. Style: Handled by ESLint/Prettier in CI — style comments in review mean a missing lint rule.
 */
Mentor's take

A checklist is only half the answer; the other half is knowing what review is for. The principle: automate every objective judgment — formatting, imports, obvious foot-guns — so human review is spent on what machines can't judge: design, correctness, naming, and knowledge transfer. That's why item 5 in this checklist is deliberately self-erasing: if a reviewer is commenting on style, the fix is a lint rule, not a review comment. Passing lint should be a CI precondition of review, not a request made in it.

The RN-specific items are where the checklist earns its keep: tokens in Keychain/Keystore rather than unencrypted AsyncStorage (that's OWASP's insecure-storage category, not a preference), deep-link parameters treated as untrusted input, and "measured, not guessed" on performance — a review that demands useMemo everywhere without a profile is cargo cult.

Process multipliers that outweigh any checklist item: small PRs (review quality collapses with diff size), author-first descriptions (what and why before the diff, so the reviewer isn't reverse-engineering intent), and review-as-partnership — the goal is helping the author ship, with the checklist as shared standard rather than ammunition.

Red flag: describing review as "catching style violations and bugs" — that frames the reviewer as a gate. The linter owns style; reviewers own design, correctness, and spreading context across the team.

Say it: "I automate the objective layer so review is spent on design and correctness — a style comment in review means we're missing a lint rule, and small PRs are the biggest review-quality lever we have."