> clean-code
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.
curl "https://skillshub.wtf/pproenca/dot-skills/clean-code?format=md"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
| Priority | Category | Impact | Prefix |
|---|---|---|---|
| 1 | Meaningful Names | CRITICAL | name- |
| 2 | Functions | CRITICAL | func- |
| 3 | Comments | HIGH | cmt- |
| 4 | Formatting | HIGH | fmt- |
| 5 | Error Handling | HIGH | err- |
| 6 | Objects and Data Structures | MEDIUM-HIGH | obj- |
| 7 | Boundaries | MEDIUM-HIGH | bound- |
| 8 | Classes and Systems | MEDIUM-HIGH | class- |
| 9 | Unit Tests | MEDIUM | test- |
| 10 | Emergence and Simple Design | MEDIUM | emerge- |
Quick Reference
1. Meaningful Names (CRITICAL)
name-intention-revealing- Use names that reveal intentname-avoid-disinformation- Avoid misleading namesname-meaningful-distinctions- Make meaningful distinctionsname-pronounceable- Use pronounceable namesname-searchable- Use searchable namesname-avoid-encodings- Avoid encodings in namesname-class-noun- Use noun phrases for class namesname-method-verb- Use verb phrases for method names
2. Functions (CRITICAL)
func-small- Keep functions smallfunc-one-thing- Functions should do one thingfunc-abstraction-level- Maintain one level of abstractionfunc-minimize-arguments- Minimize function argumentsfunc-no-side-effects- Avoid side effectsfunc-command-query-separation- Separate commands from queriesfunc-dry- Do not repeat yourself
3. Comments (HIGH)
cmt-express-in-code- Express yourself in code, not commentscmt-explain-intent- Use comments to explain intentcmt-avoid-redundant- Avoid redundant commentscmt-avoid-commented-out-code- Delete commented-out codecmt-warning-consequences- Use warning comments for consequences
4. Formatting (HIGH)
fmt-vertical-formatting- Use vertical formatting for readabilityfmt-horizontal-alignment- Avoid horizontal alignmentfmt-team-rules- Follow team formatting rulesfmt-indentation- Respect indentation rules
5. Error Handling (HIGH)
err-use-exceptions- Separate error handling from happy patherr-write-try-catch-first- Write try-catch-finally firsterr-provide-context- Provide context with exceptionserr-define-by-caller-needs- Define exceptions by caller needserr-avoid-null- Avoid returning and passing null
6. Objects and Data Structures (MEDIUM-HIGH)
obj-data-abstraction- Hide data behind abstractionsobj-data-object-asymmetry- Understand data/object anti-symmetryobj-law-of-demeter- Follow the Law of Demeterobj-avoid-hybrids- Avoid hybrid data-object structuresobj-dto- Use DTOs for data transfer
7. Boundaries (MEDIUM-HIGH)
bound-wrap-third-party- Wrap third-party APIsbound-learning-tests- Write learning tests for third-party code
8. Classes and Systems (MEDIUM-HIGH)
class-small- Keep classes smallclass-cohesion- Maintain class cohesionclass-organize-for-change- Organize classes for changeclass-isolate-from-change- Isolate classes from changeclass-separate-concerns- Separate construction from use
9. Unit Tests (MEDIUM)
test-first-law- Follow the three laws of TDDtest-keep-clean- Keep tests cleantest-one-assert- One concept per testtest-first-principles- Follow FIRST principlestest-build-operate-check- Use Build-Operate-Check pattern
10. Emergence and Simple Design (MEDIUM)
emerge-simple-design- Follow the four rules of simple designemerge-expressiveness- Maximize expressiveness
How to Use
Read individual reference files for detailed explanations and code examples:
- Section definitions - Category structure and impact levels
- Rule template - Template for adding new rules
Reference Files
| File | Description |
|---|---|
| references/_sections.md | Category definitions and ordering |
| assets/templates/_template.md | Template for new rules |
| metadata.json | Version and reference information |
> related_skills --same-repo
> rust-write-tests
Skill for writing expert-level Rust tests. Teaches the "What Could Break?" framework, five transformations from superficial to expert tests, flake hunting protocol, intent-based assertions, naming conventions, and a mandatory self-review checklist. Triggers on writing Rust tests, designing test cases, improving test quality, or reviewing test coverage.
> rust-implement
Write production-grade Rust code using a multi-pass approach. Design types first, then implement, then simplify, then verify with automated lint. Use this skill whenever writing new Rust functions, structs, modules, or features. Triggers on Rust implementation, new Rust code, Rust functions, Rust modules, error handling in Rust, async Rust, or type design in Rust.
> valid-skill
A valid test skill with proper formatting. This skill should pass all validations and serves as a reference for the expected format.
> too-long-skill
This skill has more than 500 lines which should fail validation.