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.

A local variable whose name says the same thing as the expression bound to it; reading the variable name and reading the expression resolve to the same understanding. The agent pays retrieval cost for the binding lookup that returns no information not already implied by the expression at the use site, and the extra name competes for context window space.

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.

Expressions sit at their use sites without an intervening binding; the agent reads the expression once instead of reading the variable name plus the binding's definition. The agent's token cost per read drops by the size of the binding declaration, and reasoning step count drops because no name-resolution hop intervenes between the use site and the expression's meaning.

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.

The agent tracks an extra name in scope for no reasoning benefit; reference resolution becomes a tiny hop to a definition that adds nothing. The agent's verification-surface cost on any edit touching the variable rises by one declaration to verify, and chained reads multiply the cost across every use site that resolves through the rebound name.

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.

Inlining a variable that did carry domain meaning forces the agent to interpret the bare expression every time instead of reading the named concept. The agent's completeness-check cost rises during the inline itself — every reference to the binding must be confirmed to use the inlined expression form, and any straggling reference becomes a regression.

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.

One fewer name in scope to resolve at every read; the agent loads the expression once at its single use site instead of paying the lookup hop from the variable to its definition. Token cost per edit drops because the binding declaration disappears, and context-window load contracts as the scope shrinks.

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.

Inlining a variable whose name carried a non-obvious meaning (a domain term, an intermediate result) forces the agent to re-derive the meaning of the expression at every site it appears. The agent's reasoning-step cost rises per read because the named concept now lives nowhere, and token cost multiplies across uses that would have resolved to the name.