A request with gaps
"Premium customers get a discount on large orders." Pause: define three questions that must be answered. Premium status, threshold and discount amount are not implementation details you should invent.
For this lab the owner confirms: active premium customers receive 10% off when the subtotal is strictly above 100. Existing promotions exclude the discount. Inputs are already validated.
const customerType = "premium";
const customerActive = true;
const subtotal = 120;
const hasPromotion = false;
const isPremium = customerType === "premium";
const qualifiesForAmount = subtotal > 100;
const isEligible = customerActive && isPremium && qualifiesForAmount && !hasPromotion;
let discount = 0;
if (isEligible) {
discount = subtotal * 0.10;
}
console.assert(discount === 12);
Eligibility answers a yes/no question; calculation decides an amount. Separating them helps a reviewer compare each part against the written policy. Four nested if blocks could implement the same rule but make the combined requirement harder to scan.
Guided test table
| Active | Type | Subtotal | Promotion | Discount |
|---|---|---|---|---|
| Yes | premium | 120 | No | 12 |
| Yes | premium | 100 | No | 0 |
| No | premium | 120 | No | 0 |
| Yes | standard | 120 | No | 0 |
| Yes | premium | 120 | Yes | 0 |
Change one input at a time and compare with the table. Do not infer eligibility from the string "premium" being truthy: compare it with the accepted value.
Independent lab: new policy
The threshold becomes "100 or more." Update the decision and the expected result for exactly 100. Then the owner asks for "special exceptions." Should you add a new branch immediately?
Correction
Change the threshold comparison to >=; the discount at 100 becomes 10. Other rows stay the same. Ask who qualifies for an exception and whether it overrides inactivity or promotions before adding a branch. An undefined exception cannot be implemented faithfully.
Reasoning checkpoint
Write one paragraph explaining the rule without JavaScript, and one counterexample to using OR between its requirements. Save this explanation with the code: it makes future changes reviewable.