Terse Code

Terse Code

Produce the smallest clear, correct change that fully satisfies the request.

Apply the Constraint

1. Identify the minimum required behavior and acceptance criteria before editing.
2. Inspect the relevant code and reuse existing functions, patterns, dependencies, and language features.
3. Change the fewest files and components necessary. Prefer a direct implementation over new layers, helpers, options, dependencies, or generalized frameworks.
4. Add tests, types, validation, compatibility handling, comments, and documentation only when requested or necessary for correctness, safety, repository conventions, or verification.
5. Remove duplication, dead paths, needless state, redundant wrappers, and speculative flexibility introduced by the change.
6. Review every binding and function introduced or directly modified using the checks below.
7. Run proportionate verification without adding permanent code solely to support it.

Avoid Needless Indirection

Apply these rules as review heuristics, not mechanical bans. Do not rewrite unrelated existing code solely to enforce them.

Inline One-Use Bindings

Identify variables, constants, aliases, and intermediate bindings read exactly once. Treat clusters of definitions followed by one use each as a strong warning sign. Substitute the defining expression at its sole use and remove the definition when behavior and clarity are preserved.

Inline a binding that only:

• Abbreviates the next expression, property path, call, or literal.
• Reduces line length; use normal multiline formatting instead.
• Adds a generic name such as data, result, value, item, or temp.
• Anticipates hypothetical reuse or exists for superficial consistency.

Retain a one-use binding only when inlining would:

• Change evaluation order, timing, side effects, nondeterministic behavior, an async snapshot, or resource lifetime and cleanup.
• Defeat a language or tool requirement involving ownership, borrowing, lifetimes, type checking or narrowing, pattern binding, macros, framework contracts, or build syntax.
• Remove an explicitly requested debugging, tracing, inspection, validation, or error-reporting boundary.
• Hide a genuinely important domain concept, invariant, unit, processing phase, or test role whose name makes dense code materially clearer.

Apply the final readability exception rarely. A pleasant name, shorter line, or routine step boundary is insufficient.

For example, retain this snapshot because moving its evaluation past the await changes behavior:

const snapshot = store.current;
await refreshStore();
return compare(snapshot, store.current);

Avoid Return-Only Functions

Do not create a named function, method, local helper, arrow function, or lambda whose entire behavior is returning one expression merely to shorten or label that expression. Apply this semantically even when formatting spreads the return across several lines. Substitute the returned expression at each call and inline a one-call-site wrapper by default.

Retain or create a return-only function only to:

• Satisfy a required callback, interface, override, framework hook, endpoint, dependency-injection seam, or other callable contract.
• Eliminate meaningful duplication across multiple call sites rather than wrap a trivial access or call.
• Preserve lazy evaluation, recursion, capture, generic inference, overload behavior, evaluation timing, or another language-level semantic.
• Establish a stable public API, domain policy, security boundary, or abstraction level that is materially clearer and intentionally independent of its current implementation.

Apply the final exception rarely. Hypothetical reuse, testability by itself, a desirable name, or matching nearby wrappers is insufficient. An inline callback such as records.map(record => record.id) is justified because the API requires a function value; extracting it into a separate one-line helper usually is not.

Guardrails

• Minimize concepts and maintenance burden, not merely line count.
• Prefer readable, idiomatic code over compressed, clever, or obscure code.
• Do not sacrifice correctness, error handling, security, accessibility, data integrity, required compatibility, reuse, or callable contracts to make a diff smaller.
• Do not add features, abstractions, fallback paths, extension points, or future-proofing beyond the stated job.
• Do not rewrite or clean up unrelated code to reduce it.
• Follow explicit user requirements and established repository contracts when they require a larger implementation.
• If two solutions are equally correct and clear, choose the one with less code and fewer moving parts.