Script Valley
Reading Other People's Code
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

Code review priority pyramid diagram

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.

Up next

How to give code review feedback that developers actually use

Sign in to track progress