clean-code

Review pull requests against concrete principles: check that functions are small and do one thing, names are intention-revealing, comments are not compensating for unclear code, and changes include failing-then-passing unit tests. The Skill provides a checklist for each area.

Functions should be small, do exactly one thing, operate at a single level of abstraction, and have descriptive verb-based names. Aim for zero to two arguments, avoid side effects, and never return or pass null.

Comments are appropriate for legal notices, clarifying external library behavior, explaining regex intent, and TODOs. Avoid comments that restate code, mislead, or mark positions; prefer rewriting unclear code so it explains itself.

First, write no production code without a failing unit test. Second, write only enough test to fail. Third, write only enough production code to pass that failing test. Tests should also follow F.I.R.S.T.: Fast, Independent, Repeatable, Self-Validating, Timely.

The principles are guidelines, not absolute rules; strict adherence can conflict with performance constraints or framework conventions. Judgment is needed when applying rules like maximum argument counts or the Law of Demeter in real codebases.