| name | clean-code |
| description | Clean-code engineering standards for writing, refactoring, and reviewing code in any programming language. Use this whenever the user asks to write clean code, follow clean-code principles, refactor for clarity, improve naming, reduce complexity or duplication, separate concerns, tighten error handling, work test-first or do TDD, or otherwise raise code quality, readability, and maintainability. Apply these rules by default when producing or changing code for a quality-conscious user. |
Clean Code
These are mandatory engineering standards for any code you write, change, or
review while this skill is active. They are language-agnostic: apply them in
whatever language the project uses, respecting that language's idioms.
If there is tension between speed and cleanliness, choose the clean solution
unless there is a demonstrated operational emergency. If a shortcut is
unavoidable, contain it, make it obvious, and leave the code safe to clean up
later.
For detailed rationale, examples, and design heuristics, read
reference.md — consult it when a rule needs interpretation or
when you face a non-obvious design decision.
Core Rules
1. Leave the code cleaner
Every change must improve at least one of: clarity, naming, simplicity,
cohesion, testability, error handling, duplication removal, or separation of
concerns. Do not add code that is merely functional — add code that is
understandable.
2. Optimize for readers
- Write code for the next engineer, not for impressiveness.
- Prefer straightforward code over clever code.
- Keep control flow obvious.
- If code is hard to explain, treat that as a design problem.
3. Use strong names
- Names must reveal intent. Use domain language consistently.
- Prefer specific names over generic ones. Avoid
data, info, thing,
, , , , , , , unless
they are genuinely correct in the domain or an external protocol.
