What I Look for in Code Reviews
Code review isn't about gatekeeping. It's about making code better together. Here's what I focus on.
Beyond "Looks Good"
Rubber-stamping PRs doesn't help anyone. But neither does nitpicking semicolons. Here's what actually matters.
Correctness
Does it do what it's supposed to?
- Read the ticket/issue first
- Trace through the logic
- Think about edge cases
- Check error handling
Clarity
Will someone understand this in 6 months?
// ❌ What does this do?
const f = x => x.filter(i => i.s === 'a').map(i => i.n);
// ✅ Self-documenting
const getActiveUserNames = users =>
users
.filter(user => user.status === 'active')
.map(user => user.name);Names matter. Structure matters.
Consistency
Does it follow existing patterns?
If the codebase does errors one way, new code should match:
// If existing code does:
throw new AppError('NOT_FOUND', 'User not found', 404);
// Don't introduce:
res.status(404).send({ error: 'not found' });Testing
- Are there tests?
- Do they test the right things?
- Will they catch regressions?
I'm not dogmatic about coverage percentages, but critical paths need tests.
Security
Red flags to catch:
- Raw SQL queries (SQL injection)
- Unsanitized user input
- Secrets in code
- Missing authentication checks
Performance
For hot paths:
- Unnecessary loops or computations
- N+1 queries
- Missing indexes
- Large payloads
How I Comment
Good
"This could throw if user is null - should we add a check?"
"Nice approach! One thought: we could extract this into a hook
for reuse in UserProfile."Not Helpful
"Wrong."
"I would have done this differently."
"Nit: spacing"Be specific. Explain why. Suggest alternatives.
Remember
Code review is collaboration, not judgment. The goal is better code, not proving who's smarter.