Foundations — Code review — what to look for

Before you can read the parent note, you need to understand the words and symbols it throws around as if you already knew them. This page builds each one from nothing. Read top to bottom — every idea uses only the ones above it.

1. The raw materials — what a "change" actually is

Look at the figure below. The left column is the file before; the right is the file after. The red lines are the diff — the only thing a reviewer really looks at.

Why the topic needs this: a review examines a diff, not a whole program. If you didn't know what a diff was, "reviewing a change" would sound like re-reading the entire codebase every time — which nobody does.

2. The people and the timeline

Why the topic needs this: the entire cost argument is "catch the bug at the leftmost stage." Without the belt picture, $s=0,1,2$ are just meaningless numbers.

3. The symbols in the cost formula

The parent writes ${\text{cost}}_{\text{fix}}\approx c_0\cdot k^s$. Let's earn every letter.

Why an exponent and not just $c_0+k\cdot s$ (a straight line)? Because the badness compounds: each stage multiplies the mess left by the previous stage, it doesn't merely add a fixed chunk. That's the difference between linear ($+$) and exponential ($\times$) growth.

Look at the figure: the straight black dashed line (adding) barely climbs; the red curve (multiplying) explodes. The gap between them is the value of catching bugs early.

4. The symbols in the "is it worth it?" formula

The parent's payoff line is $R<np{c}_0(k^2-1)$. We will now build it from scratch, so the $(k^2-1)$ term is no longer a mystery. New symbols first:

Building the payoff, one $E$ at a time

Step 1 — WHAT: split the $n$ bugs into two buckets. With review, each bug is either caught now (probability $p$) or escapes (probability $1-p$). Multiply the count $n$ by each probability:

• caught at review: $np$ bugs, each costing $c_0$ (stage $s=0$);
• escaped: $n(1-p)$ bugs, each costing $c_0{k}^2$ (stage $s=2$).

Step 2 — WHY expected value: we don't know which bugs escape, so we can't add exact costs. Instead we weight each cost by its probability and sum — that is exactly what $E$ means. Add the reviewer's own time $R$, since running the review isn't free:

Step 3 — the comparison: with no review, nobody catches anything, so every bug reaches production:

Step 4 — WHAT we want: review is worth it when it costs less, $E_{\text{review}}<E_{\text{none}}$. Subtract and watch $(k^2-1)$ appear: $n{c}_0{k}^2-(np{c}_0+n(1-p)c_0{k}^2+R)>0$ Group the $k^2$ terms — $n{c}_0{k}^2-n(1-p)c_0{k}^2=np{c}_0{k}^2$ — then subtract the $np{c}_0$: $np{c}_0{k}^2-np{c}_0-R>0⟹np{c}_0(k^2-1)>R$

5. Concepts the priority ladder assumes

The parent ranks: Correctness → Design → Security → Tests → Readability → Performance → Style. Each rung leans on an idea — here are the ones the parent never pauses to define:

How these feed the topic

Everything on the left is a foundation; the two arrows into "Code review what to look for" are the two halves of the parent: why it pays (the formula) and what to check (the ladder).

Equipment checklist

Cover the right side and see if you can answer each before revealing.

Connections

• Yeh note Hinglish mein padho →
• Pull requests and Git workflow — where diffs and PRs come from.
• Unit testing — the "Tests" rung of the ladder.
• SQL injection and input validation — the "Security" rung.
• Big-O notation — the "Performance" rung.
• Technical debt — what design comments prevent.
• Refactoring — cleaning up once a linter or reviewer flags something.