Clean Code Reference
A comprehensive reference for writing clean, maintainable code based on Robert Martin's "Clean Code" and related works. This skill provides language-agnostic principles with examples that apply to any programming language.
When This Skill Activates
This skill automatically activates when you:
- Review code for quality or maintainability
- Need guidance on naming conventions
- Discuss refactoring or code smells
- Apply SOLID principles
- Improve code readability or structure
- Write or review unit tests
Quick Reference
SOLID Principles
| Principle |
Summary |
Violation Sign |
| Single Responsibility (SRP) |
One reason to change |
Class does too many things |
| Open/Closed (OCP) |
Open for extension, closed for modification |
Modifying existing code for new features |
| Liskov Substitution (LSP) |
Subtypes must be substitutable |
Subclass breaks parent behavior |
| Interface Segregation (ISP) |
No forced dependencies on unused methods |
Fat interfaces |
| Dependency Inversion (DIP) |
Depend on abstractions, not concretions |
High-level modules import low-level |
Clean Code Practices
| Practice |
Key Points |
| Meaningful Names |
Intention-revealing, pronounceable, searchable |
| Functions |
Small, do one thing, one level of abstraction |
| Comments |
Code should be self-documenting; comments explain why, not what |
| Formatting |
Consistent style, vertical density, horizontal alignment |
| Error Handling |
Exceptions over error codes, fail fast, don't return null |
| Unit Testing |
F.I.R.S.T. principles, one assert per test, test behavior |
| Code Smells |
Recognition and refactoring of common problems |
| Boy Scout Rule |
Leave code cleaner than you found it |
The Boy Scout Rule
"Leave the campground cleaner than you found it."
Every time you touch code, make it a little better. Small, incremental improvements compound over time.
Code Quality Checklist
Before committing code, verify:
Language Translation Notes
Examples use generic pseudocode. Adapt to your language:
- PHP:
class, function, ->, type hints
- JavaScript/TypeScript:
class, arrow functions, .
- Python:
class, def, ., type hints
- Java/C#: Direct mapping with access modifiers
Based on concepts from "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, 2008.
1---2name: clean-code-83description: Clean Code principles and practices reference based on Robert Martin's work. Use this skill when reviewing code quality, naming conventions, refactoring, or applying SOLID principles. Auto-activates for code smell detection, style improvements, and maintainability concerns.4---5
6# Clean Code Reference
7
8A comprehensive reference for writing clean, maintainable code based on Robert Martin's "Clean Code" and related works. This skill provides language-agnostic principles with examples that apply to any programming language.
9
10## When This Skill Activates
11
12This skill automatically activates when you:
13- Review code for quality or maintainability
14- Need guidance on naming conventions
15- Discuss refactoring or code smells
16- Apply SOLID principles
17- Improve code readability or structure
18- Write or review unit tests
19
20## Quick Reference
21
22### SOLID Principles
23| Principle | Summary | Violation Sign |
24|-----------|---------|----------------|
25| [Single Responsibility (SRP)](solid/single-responsibility.md) | One reason to change | Class does too many things |
26| [Open/Closed (OCP)](solid/open-closed.md) | Open for extension, closed for modification | Modifying existing code for new features |
27| [Liskov Substitution (LSP)](solid/liskov-substitution.md) | Subtypes must be substitutable | Subclass breaks parent behavior |
28| [Interface Segregation (ISP)](solid/interface-segregation.md) | No forced dependencies on unused methods | Fat interfaces |
29| [Dependency Inversion (DIP)](solid/dependency-inversion.md) | Depend on abstractions, not concretions | High-level modules import low-level |
30
31### Clean Code Practices
32| Practice | Key Points |
33|----------|------------|
34| [Meaningful Names](practices/meaningful-names.md) | Intention-revealing, pronounceable, searchable |
35| [Functions](practices/functions.md) | Small, do one thing, one level of abstraction |
36| [Comments](practices/comments.md) | Code should be self-documenting; comments explain why, not what |
37| [Formatting](practices/formatting.md) | Consistent style, vertical density, horizontal alignment |
38| [Error Handling](practices/error-handling.md) | Exceptions over error codes, fail fast, don't return null |
39| [Unit Testing](practices/unit-testing.md) | F.I.R.S.T. principles, one assert per test, test behavior |
40| [Code Smells](practices/code-smells.md) | Recognition and refactoring of common problems |
41| [Boy Scout Rule](practices/boy-scout-rule.md) | Leave code cleaner than you found it |
42
43## The Boy Scout Rule
44
45> "Leave the campground cleaner than you found it."
46
47Every time you touch code, make it a little better. Small, incremental improvements compound over time.
48
49## Code Quality Checklist
50
51Before committing code, verify:
52
53- [ ] **Names** - Are all names intention-revealing?
54- [ ] **Functions** - Is each function doing exactly one thing?
55- [ ] **Comments** - Are comments explaining why, not what?
56- [ ] **DRY** - Is there any duplicated logic?
57- [ ] **SOLID** - Are principles being followed?
58- [ ] **Tests** - Is the code tested and testable?
59- [ ] **Error Handling** - Are errors handled gracefully?
60
61## Language Translation Notes
62
63Examples use generic pseudocode. Adapt to your language:
64- **PHP**: `class`, `function`, `->`, type hints
65- **JavaScript/TypeScript**: `class`, arrow functions, `.`
66- **Python**: `class`, `def`, `.`, type hints
67- **Java/C#**: Direct mapping with access modifiers
68
69---
70
71*Based on concepts from "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, 2008.*
majiayu000