Multi-clause conditionals whose meaning isn't obvious from the expression — `if (date.getMonth() >= 5 && date.getMonth() <= 8)` instead of `if (isSummer(date))`.
Multi-clause conditional expressions whose domain meaning isn't readable from the syntax; the agent must parse the expression every time it encounters it.
Conditions and their consequents read as named domain decisions: isInSummer(), discountFor(date), etc.
Conditions read as named domain decisions; the agent reasons about isSummer(date) instead of re-deriving the month range.
Before the refactoring
if (date < SUMMER_START || date > SUMMER_END) {charge = qty * winterRate + winterFee;} else {charge = qty * summerRate;}
After the refactoring
charge = isSummer(date)? summerCharge(qty): winterCharge(qty);
Readers parse the expression every time; comments accumulate to explain what it means; debugging requires evaluating the expression mentally.
The agent re-parses the expression at every reference; debugging the condition's value requires the agent to mentally evaluate the full chain.
Names that aren't crisper than the underlying condition add ceremony — only extract when the named function/variable says something the condition can't.
Extracted names that aren't crisper than the original condition add a layer of indirection — the agent now follows a name to find the same expression.
The branching logic reads top-to-bottom as a story; bugs concentrate in the named pieces.
Each condition and branch lives at one named function the agent reads against the function's name instead of recovering the predicate's domain meaning from its boolean expression.
Extracting names that aren't crisper than the underlying condition — adds a layer of indirection without revealing intent.
Extracting names that don't sharpen the condition — `isMonthBetweenFiveAndEight` instead of `isSummer` — adds indirection without revealing intent.