Refactor Code to Clean Code Standards

This skill embodies the principles of Robert C. Martin's (Uncle Bob's) "Clean Code" to transform "code that works" into "code that is clean" - code that can be read and enhanced by a developer other than its original author.

It covers meaningful names (intention-revealing names like elapsedTimeInDays instead of d, avoiding disinformation such as calling a Map an accountList, nouns for classes, verbs for methods); functions (small, doing one thing, one level of abstraction, descriptive names like isPasswordValid over check, 0-2 arguments ideally, no hidden side effects); comments (don't comment bad code - rewrite it; prefer expressing intent in code, e.g. isEligibleForFullBenefits() over a comment plus a raw boolean condition; good comments are legal, informative, or clarifying - bad ones are mumbling, redundant, misleading, or noise); formatting (the newspaper metaphor - high-level concepts at the top, details at the bottom; vertical density and distance; consistent indentation).

It also covers objects and data structures (data abstraction hiding implementation behind interfaces, the Law of Demeter against chains like a.getB().getC().doSomething(), DTOs as classes with public variables and no functions); error handling (exceptions over return codes, try-catch-finally written first, never returning or passing null); unit tests (the Three Laws of TDD - no production code before a failing test, no more test than needed to fail, no more production code than needed to pass; the F.I.R.S.T. principles - Fast, Independent, Repeatable, Self-Validating, Timely); classes (small, single-responsibility, the Stepdown Rule for top-down readability); and code smells and heuristics (rigidity, fragility, immobility, viscosity, needless complexity and repetition).

It includes an implementation checklist: is this function under 20 lines, does it do exactly one thing, are all names searchable and intention-revealing, have comments been avoided by clarifying the code itself, are there too many arguments, is there a failing test for this change.

Use this skill when writing new code to ensure quality from the start, reviewing pull requests to give principle-based feedback, refactoring legacy code to remove smells, or aligning a team on industry-standard best practices.

Only apply it when the task clearly matches this scope - it is not a substitute for environment-specific validation, testing, or expert review, and requires clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Inputs: code to write, review, or refactor.

Outputs: code and PR feedback aligned with Clean Code principles - meaningful names, small single-purpose functions and classes, minimal/clarifying comments, consistent formatting, proper error handling via exceptions (never null), and TDD-driven tests.

Applicable across languages; examples in the source use Python.

Developers writing new code, reviewing pull requests, refactoring legacy code, or establishing team coding standards based on Robert C. Martin's Clean Code principles.