| name | code-style |
| description | Enforce existence, reuse, mirror, and symmetry principles to keep new code minimal and consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes. |
Code Style: Exist, Reuse, Mirror, Symmetry
When writing new code in an existing codebase, work through these in order. When two pull in different directions, the earlier one wins.
- Establish that the code needs to exist: Drop work the request does not need — an abstraction with one implementation, a configuration point with one caller, a branch for a state the callers cannot reach, scaffolding for an anticipated requirement. Deleting or narrowing beats adding. Before removing code that already exists, trace its callers and confirm nothing depends on the behavior. Input validation at trust boundaries, error handling that prevents data loss, security controls, accessibility affordances, and anything explicitly requested outrank this rule.
- Reuse existing code: Before writing a new helper, check if an existing method can be reused or generalized. If a new helper is needed, model it after its closest sibling.
- Reuse existing patterns: Find the closest analogous feature and replicate its structure (method decomposition, control flow, annotations, guard clauses). When an existing pattern fits, use it rather than introducing a new one. When following it would force materially more code or indirection than a different approach, take the different approach and apply it across the whole change.
- Mirror the surrounding code exactly: Match brace style, comment style, naming conventions, blank line spacing, code density, and level of detail by reading nearby code first.
- Maintain symmetry: If adding
fooB() parallel to fooA(), match naming, parameter order, and structure. Symmetry covers every name the new sibling makes asymmetric: identifiers, route paths, config keys, event names, environment variables, CLI flags, and file naming schemes. Rename the existing name by default; keep it as it stands only when it is a published contract whose consumers you cannot update, or cannot update in step with the rename. Treat deployment and registration as costs the change absorbs: updating every place the name is referenced or registered is part of the change.