Code Review: Reading Others' ChangesLesson 6.2
What to actually look for when reviewing someone's code
correctness over style, logic errors, edge case coverage, security implications, performance implications, error handling completeness, test quality
Review for Correctness, Not Preference
Most review comments are about style. Most bugs come from correctness and logic errors. Review in priority order: correctness first, design second, style last (and let the linter handle most of style).
Correctness Checklist
// 1. Does every code path handle errors?
async function getUser(id) {
const user = await db.findById(id);
return user.profile; // Bug: user could be null if ID doesn't exist
}
// 2. Are there off-by-one errors in loops?
for (let i = 0; i <= items.length; i++) { // Bug: should be <, not <=
// 3. Is mutable state shared unsafely?
const DEFAULT_OPTIONS = { timeout: 5000, retries: 3 };
function request(url, options = DEFAULT_OPTIONS) {
options.retries--; // Bug: mutates the shared DEFAULT_OPTIONS object
...
}
// 4. Is user input validated before use?
function query(userId) {
return db.raw(`SELECT * FROM users WHERE id = ${userId}`); // SQL injection
}Security Is Always In Scope
Every code review should check: is user input sanitized before DB queries or HTML rendering? Are authentication checks present on new routes? Are secrets ever logged? Are error messages leaking internal details to clients? These are high-value bugs that static analysis often misses.
