Clean Code Skill
Core Principles
1. Meaningful Names
# Bad
def calc(a, b):
return a * b
# Good
def calculate_total_price(unit_price: float, quantity: int) -> float:
return unit_price * quantity
2. Single Responsibility
# Bad - does too much
def process_user(user_data):
validate(user_data)
user = create_user(user_data)
send_welcome_email(user)
log_creation(user)
return user
# Good - each function does one thing
def create_user(user_data: UserData) -> User:
return User(**user_data)
def onboard_user(user_data: UserData) -> User:
user = create_user(user_data)
send_welcome_email(user)
log_user_creation(user)
return user
3. DRY (Don't Repeat Yourself)
# Bad
def get_active_users():
return [u for u in users if u.status == "active"]
def get_active_admins():
return [u for u in users if u.status == "active" and u.role == "admin"]
# Good
def filter_users(status: str | None = None, role: str | None = None) -> list[User]:
result = users
if status:
result = [u for u in result if u.status == status]
if role:
result = [u for u in result if u.role == role]
return result
Code Organization
Keep modules focused. Order contents consistently: imports (stdlib, third-party, local), constants, public API, private helpers. Use clear visibility markers (underscore prefix in Python, access modifiers in other languages). Group related functionality into cohesive modules rather than dumping everything into a single file.
Anti-Patterns to Avoid
| Anti-Pattern |
Problem |
Solution |
| God class |
Too many responsibilities |
Split into smaller classes |
| Long methods |
Hard to understand |
Extract methods |
| Deep nesting |
Complex control flow |
Early returns, extract methods |
| Magic numbers |
Unclear meaning |
Use named constants |
| Bare except |
Hides bugs |
Catch specific exceptions |
| Mutable defaults |
Shared state bugs |
Use None and create inside |
Quality Checklist
Common Rationalizations
| Excuse |
Why It's Wrong |
| "It's readable enough" |
"Enough" means someone will misread it eventually — clarity prevents incidents |
| "Refactoring for readability is gold-plating" |
Readability is maintainability — future you will thank present you |
| "Short variable names are faster to type" |
You type it once, readers parse it hundreds of times — optimize for reading |
| "DRY means never repeat anything" |
Wrong DRY creates coupling — duplicate until you see the real abstraction |
| "More abstractions = cleaner code" |
Premature abstraction is worse than duplication — wait for the third use |
| "That dead file is pre-existing, not my problem" |
If your change makes it verifiably unused, deleting it IS your problem (Constitution Art. VI.1) |
| "I'll fix the missing test in a separate PR" |
Forbidden when the test covers behavior you just changed — add it now (Constitution Art. VI.2) |
| "Świadome pominięcie" / "out of scope" |
Deferral of directly-adjacent fixes is forbidden; if a user decision is needed, ASK, don't bury it |
Language-Specific References
For detailed patterns, type hints, linting configuration, and idiomatic code per language:
- Python: type hints, docstrings, error handling, context managers, module/class structure, ruff/mypy config -- see reference/python.md
- TypeScript: strict tsconfig, ESLint setup, discriminated unions, type safety -- see reference/typescript.md
- PHP: PHPStan config, PSR-12, enums, constructor promotion -- see reference/php.md
- Go: gofmt, error handling, receiver naming, early returns -- see reference/go.md
- Dart/Flutter: null safety, named parameters, const constructors, dart analyze -- see reference/dart.md
1---2name: clean-code3description: Code quality: meaningful names, SRP, DRY, small functions, guard clauses, refactoring. Triggers: clean code, naming, code smell, SRP, DRY, long function, god class, dead code.4---56# Clean Code Skill78## Core Principles910### 1. Meaningful Names1112```python13# Bad14def calc(a, b):15 return a * b1617# Good18def calculate_total_price(unit_price: float, quantity: int) -> float:19 return unit_price * quantity20```2122### 2. Single Responsibility2324```python25# Bad - does too much26def process_user(user_data):27 validate(user_data)28 user = create_user(user_data)29 send_welcome_email(user)30 log_creation(user)31 return user3233# Good - each function does one thing34def create_user(user_data: UserData) -> User:35 return User(**user_data)3637def onboard_user(user_data: UserData) -> User:38 user = create_user(user_data)39 send_welcome_email(user)40 log_user_creation(user)41 return user42```4344### 3. DRY (Don't Repeat Yourself)4546```python47# Bad48def get_active_users():49 return [u for u in users if u.status == "active"]5051def get_active_admins():52 return [u for u in users if u.status == "active" and u.role == "admin"]5354# Good55def filter_users(status: str | None = None, role: str | None = None) -> list[User]:56 result = users57 if status:58 result = [u for u in result if u.status == status]59 if role:60 result = [u for u in result if u.role == role]61 return result62```6364---6566## Code Organization6768Keep modules focused. Order contents consistently: imports (stdlib, third-party, local), constants, public API, private helpers. Use clear visibility markers (underscore prefix in Python, access modifiers in other languages). Group related functionality into cohesive modules rather than dumping everything into a single file.6970---7172## Anti-Patterns to Avoid7374| Anti-Pattern | Problem | Solution |75|--------------|---------|----------|76| God class | Too many responsibilities | Split into smaller classes |77| Long methods | Hard to understand | Extract methods |78| Deep nesting | Complex control flow | Early returns, extract methods |79| Magic numbers | Unclear meaning | Use named constants |80| Bare except | Hides bugs | Catch specific exceptions |81| Mutable defaults | Shared state bugs | Use `None` and create inside |8283---8485## Quality Checklist8687- [ ] Functions are small (<20 lines ideal)88- [ ] Names are descriptive and consistent89- [ ] Type hints on all public APIs90- [ ] Docstrings on all public functions/classes91- [ ] No magic numbers (use constants)92- [ ] No hardcoded strings (use enums/constants)93- [ ] Error handling is specific94- [ ] Resources are properly cleaned up95- [ ] No code duplication96- [ ] Tests cover critical paths97- [ ] **No dead code** — grep-verified zero references for every removed/renamed symbol; pre-existing dead code touched by this change is deleted too (Constitution Art. VI.1)98- [ ] **Every found bug fixed** — bugs, missing tests for changed behavior, and stale docs discovered during the task are fixed in the same change, not deferred (Constitution Art. VI.2)99100---101102## Common Rationalizations103104| Excuse | Why It's Wrong |105|--------|----------------|106| "It's readable enough" | "Enough" means someone will misread it eventually — clarity prevents incidents |107| "Refactoring for readability is gold-plating" | Readability is maintainability — future you will thank present you |108| "Short variable names are faster to type" | You type it once, readers parse it hundreds of times — optimize for reading |109| "DRY means never repeat anything" | Wrong DRY creates coupling — duplicate until you see the real abstraction |110| "More abstractions = cleaner code" | Premature abstraction is worse than duplication — wait for the third use |111| "That dead file is pre-existing, not my problem" | If your change makes it verifiably unused, deleting it IS your problem (Constitution Art. VI.1) |112| "I'll fix the missing test in a separate PR" | Forbidden when the test covers behavior you just changed — add it now (Constitution Art. VI.2) |113| "Świadome pominięcie" / "out of scope" | Deferral of directly-adjacent fixes is forbidden; if a user decision is needed, ASK, don't bury it |114115## Language-Specific References116117For detailed patterns, type hints, linting configuration, and idiomatic code per language:118119- **Python:** type hints, docstrings, error handling, context managers, module/class structure, ruff/mypy config -- see [reference/python.md](reference/python.md)120- **TypeScript:** strict tsconfig, ESLint setup, discriminated unions, type safety -- see [reference/typescript.md](reference/typescript.md)121- **PHP:** PHPStan config, PSR-12, enums, constructor promotion -- see [reference/php.md](reference/php.md)122- **Go:** gofmt, error handling, receiver naming, early returns -- see [reference/go.md](reference/go.md)123- **Dart/Flutter:** null safety, named parameters, const constructors, dart analyze -- see [reference/dart.md](reference/dart.md)