Clean Code

This skill covers writing code that is easy to read and change, and — just as important — avoiding the over-engineering that makes code harder to read and change in the name of "best practices." Both halves matter together: clean code is simple code, not merely well-decorated code.

Workflow for Writing or Reviewing Code

1. Scope the change — Identify exactly what was asked for. Note what's out of scope before writing anything.
2. Reach for the simplest solution first — Prefer the direct, obvious implementation over a general or configurable one, unless a concrete current need justifies more.
3. Name things for their purpose — Choose names that reveal intent before writing the body of a function or the shape of a type.
4. Keep functions single-purpose — If a function needs a comment to explain what it does, split it.
5. Remove duplication deliberately — Extract shared logic only once it's actually duplicated (see Rule of Three below), not preemptively.
6. Write or update tests — Cover the new behavior and the edge cases it introduces.
7. Verify scope before delivery — Confirm only the requested code changed, check for a simpler approach you might have missed, and confirm no unrequested files were touched.

Meaningful Names

• Variables, functions, and classes should reveal their purpose from the name alone.
• Names should explain why something exists and how it's used, not just its type or contents (activeUserIds, not list1).
• Avoid abbreviations unless they're universally understood in the domain (id, url — fine; usrCfgTmp — not fine).