Inline Variable

A local variable that's just a rename of its right-hand side — `const basePrice = order.basePrice;` — adding no domain meaning the original expression didn't already carry. The reader pays comprehension cost for a binding that returns no information, and small scopes accumulate redundant names that crowd out the meaningful variables.

Single-use variables that just rename their right-hand side disappear; the expression speaks for itself. The reader's mental effort per read drops by the name-lookup hop the binding required, and signal-to-noise ratio of the scope rises as redundant names give way to the expressions they merely renamed.

Readers track an extra name for nothing; small scopes accumulate redundant references; the variable's existence implies meaning it doesn't have. The team's verification cost on edits touching the binding rises by one declaration to verify on every change, and reviewers grant the binding presumed meaning that isn't there.

Inlining a name that did carry domain meaning costs readability — only inline when the expression is already self-explanatory. The team's maintenance cost can rise rather than drop if inlining strips a name that was load-bearing across multiple reads, because the original named concept now lives nowhere in the scope.

Less local clutter, fewer redundant names, smaller scopes to track. The team's enhancement cost drops because adding a new use of the expression doesn't require updating a binding's name, and reviewers focus on the meaning at the use site rather than reconciling the binding's name with the expression it merely renamed.

Inlining a variable whose name did carry domain meaning — collapsing `const annualRate = 0.05` to bare `0.05` strips the named constant the reader needed. The cognitive load of decoding what `0.05` means at every use site rises, and the cure adds accidental complexity by stripping the named domain concept the binding was holding.