Clean Code

by pproencacf93c57cac89No license215 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 7 weeks ago

Use when writing, reviewing, or refactoring code for maintainability and readability. Triggers on code reviews, naming discussions, function design, error handling, and test writing. Based on Robert C. Martin's Clean Code handbook with modern corrections.

Instructions onlySoftware Development
AI-generated overview

A reference guide of 48 Clean Code rules for writing, reviewing and refactoring maintainable code.

What it does
This skill supplies a structured set of 48 software craftsmanship rules drawn from Robert C. Martin's Clean Code, organized into 10 prioritized categories such as naming, functions, comments, formatting, error handling, objects, boundaries, classes, unit tests and simple design. Each rule is documented in its own reference file with explanations and code examples, mostly in Java but described as language-agnostic. It produces guidance used during code reviews, refactoring decisions and new development rather than generating files or running tools.
When to use it
Use it when writing new functions, classes or modules, naming variables and methods, or reviewing code for maintainability. It also fits refactoring existing code for clarity, improving unit tests, and wrapping third-party dependencies.
Requirements
No scripts, packages or credentials; it is an instructions-and-references skill that only needs the agent to read its markdown files.

Robert C. Martin (Uncle Bob) Clean Code Best Practices

Comprehensive software craftsmanship guide based on Robert C. Martin's "Clean Code: A Handbook of Agile Software Craftsmanship", updated with modern corrections where the original 2008 advice has been superseded. Contains 48 rules across 10 categories, prioritized by impact to guide code reviews, refactoring decisions, and new development. Examples are primarily in Java but principles are language-agnostic.

When to Apply

Reference these guidelines when:

  • Writing new functions, classes, or modules
  • Naming variables, functions, classes, or files
  • Reviewing code for maintainability issues
  • Refactoring existing code to improve clarity
  • Writing or improving unit tests
  • Wrapping third-party dependencies

Rule Categories by Priority

PriorityCategoryImpactPrefix
1Meaningful NamesCRITICALname-
2FunctionsCRITICALfunc-
3CommentsHIGHcmt-
4FormattingHIGHfmt-
5Error HandlingHIGHerr-
6Objects and Data StructuresMEDIUM-HIGHobj-
7BoundariesMEDIUM-HIGHbound-
8Classes and SystemsMEDIUM-HIGHclass-
9Unit TestsMEDIUMtest-
10Emergence and Simple DesignMEDIUMemerge-

Quick Reference

1. Meaningful Names (CRITICAL)

  • name-intention-revealing [blocked] - Use names that reveal intent
  • name-avoid-disinformation [blocked] - Avoid misleading names
  • name-meaningful-distinctions [blocked] - Make meaningful distinctions
  • name-pronounceable [blocked] - Use pronounceable names
  • name-searchable [blocked] - Use searchable names
  • name-avoid-encodings [blocked] - Avoid encodings in names
  • name-class-noun [blocked] - Use noun phrases for class names
  • name-method-verb [blocked] - Use verb phrases for method names

2. Functions (CRITICAL)

  • func-small [blocked] - Keep functions small
  • func-one-thing [blocked] - Functions should do one thing
  • func-abstraction-level [blocked] - Maintain one level of abstraction
  • func-minimize-arguments [blocked] - Minimize function arguments
  • func-no-side-effects [blocked] - Avoid side effects
  • func-command-query-separation [blocked] - Separate commands from queries
  • func-dry [blocked] - Do not repeat yourself

3. Comments (HIGH)

  • cmt-express-in-code [blocked] - Express yourself in code, not comments
  • cmt-explain-intent [blocked] - Use comments to explain intent
  • cmt-avoid-redundant [blocked] - Avoid redundant comments
  • cmt-avoid-commented-out-code [blocked] - Delete commented-out code
  • cmt-warning-consequences [blocked] - Use warning comments for consequences

4. Formatting (HIGH)

  • fmt-vertical-formatting [blocked] - Use vertical formatting for readability
  • fmt-horizontal-alignment [blocked] - Avoid horizontal alignment
  • fmt-team-rules [blocked] - Follow team formatting rules
  • fmt-indentation [blocked] - Respect indentation rules

5. Error Handling (HIGH)

  • err-use-exceptions [blocked] - Separate error handling from happy path
  • err-write-try-catch-first [blocked] - Write try-catch-finally first
  • err-provide-context [blocked] - Provide context with exceptions
  • err-define-by-caller-needs [blocked] - Define exceptions by caller needs
  • err-avoid-null [blocked] - Avoid returning and passing null

6. Objects and Data Structures (MEDIUM-HIGH)

  • obj-data-abstraction [blocked] - Hide data behind abstractions
  • obj-data-object-asymmetry [blocked] - Understand data/object anti-symmetry
  • obj-law-of-demeter [blocked] - Follow the Law of Demeter
  • obj-avoid-hybrids [blocked] - Avoid hybrid data-object structures
  • obj-dto [blocked] - Use DTOs for data transfer

7. Boundaries (MEDIUM-HIGH)

  • bound-wrap-third-party [blocked] - Wrap third-party APIs
  • bound-learning-tests [blocked] - Write learning tests for third-party code

8. Classes and Systems (MEDIUM-HIGH)

  • class-small [blocked] - Keep classes small
  • class-cohesion [blocked] - Maintain class cohesion
  • class-organize-for-change [blocked] - Organize classes for change
  • class-isolate-from-change [blocked] - Isolate classes from change
  • class-separate-concerns [blocked] - Separate construction from use

9. Unit Tests (MEDIUM)

  • test-first-law [blocked] - Follow the three laws of TDD
  • test-keep-clean [blocked] - Keep tests clean
  • test-one-assert [blocked] - One concept per test
  • test-first-principles [blocked] - Follow FIRST principles
  • test-build-operate-check [blocked] - Use Build-Operate-Check pattern

10. Emergence and Simple Design (MEDIUM)

  • emerge-simple-design [blocked] - Follow the four rules of simple design
  • emerge-expressiveness [blocked] - Maximize expressiveness

How to Use

Read individual reference files for detailed explanations and code examples:

  • Section definitions [blocked] - Category structure and impact levels
  • Rule template [blocked] - Template for adding new rules

Reference Files

FileDescription
references/_sections.md [blocked]Category definitions and ordering
assets/templates/_template.md [blocked]Template for new rules
metadata.json [blocked]Version and reference information

Source and attribution

Source:pproenca/dot-skillsinskills/.experimental/clean-codeat commitcf93c57

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal