- 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. A new test must earn its place too: before adding one, name the behavior it protects and the credible regression that makes it fail, and confirm no existing test already fails on that regression. When a mutation run checks the new test, read every test that fails under it, not only the new one: if existing tests also fail, keep the new test only for a regression they miss. When an existing test covers the same contract, extend its cases instead. Drive the test through a boundary production code already uses rather than adding an export, flag, or hook that only the test calls. A test pins the behavior it is named for: when one you add or change also covers another behavior only through how it is set up, give that behavior its own test unless another test already fails when it breaks, and set the first test up the way its siblings are. 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 tofooA(), 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.