Code Style — Compact and Readable

Write only what the task needs, with names and control flow a reader can understand directly. Compactness comes from removing unnecessary concepts and indirection; keep normal formatting and useful intermediate variables. Code explains what; comments preserve context the code cannot express. Part of the dev-* development-cycle skill set (see dev-cycle).

Before Adding Code

Read the affected flow and its callers, including consumers of changed return values, errors, and side effects. Check whether configuration or an existing capability already meets the request; do not remove requested behavior as a shortcut. Then choose the simplest implementation that meets the actual contract:

1. Reuse suitable code already in the project when its semantics and module boundary fit.
2. Prefer standard-library or native platform capabilities when they cover the required behavior.
3. Use an installed dependency when it fits better; add a dependency only when its benefit justifies the ongoing cost.
4. Otherwise write the small, direct implementation. Omit speculative options, extension points, and scaffolding.

Preserve requested behavior, validation at trust boundaries, necessary error handling, security, accessibility, and meaningful tests. A shorter diff that leaves the root cause or a requirement unresolved is incomplete.

Make the Code Explain Itself