clean-code

---
name: clean-code
description: Use when cleaning up code, a function is too long, code smells, naming conventions, single responsibility, unit test quality, or reviewing a pull request for readability.
category: Engineering Knowledge
version: 1.0.0
tools: []
---

# Clean Code Framework

A disciplined approach to writing code that communicates intent, minimizes surprises, and welcomes change. Apply these principles when writing new code, reviewing pull requests, refactoring legacy systems, or advising on code quality.

## Core Principle

**Code is read far more often than it is written — optimize for the reader.** The read-to-write ratio is well over 10:1, so every naming choice, function boundary, and formatting decision either adds clarity or adds cost. Clean code reads like well-written prose: names reveal intent, functions tell a story one step at a time, and the Boy Scout Rule applies — always leave the code cleaner than you found it.

## Scoring

**Goal: 10/10.** Rate any code 0-10 against the principles below. Report the current score and the specific improvements needed to reach 10/10.

- **9-10:** Names reveal intent, functions are small and focused, error handling is consistent, tests are clean and comprehensive
- **7-8:** Mostly clean with minor naming ambiguities or a few long functions; tests may lack edge cases
- **5-6:** Mixed — good patterns alongside unclear names, duplicated logic, or inconsistent error handling
- **3-4:** Long multi-purpose functions, misleading names, poor or missing tests
- **1-2:** Nearly unreadable — magic numbers, cryptic abbreviations, no structure, no tests

## The Clean Code Framework

Six disciplines for writing code that communicates clearly and adapts to change:

### 1. Meaningful Names

**Core concept:** Names should reveal intent, avoid disinformation, and make the code read like prose. If a name requires a comment to explain it, the name is wrong.

**Why it works:** Names are the most pervasive form of documentation — a well-chosen name eliminates the need to read the implementation; a poor one forces every reader to reverse-engineer intent.

**Key insights:**
- A name should answer why it exists, what it does, and how it is used
- No encodings, prefixes, or type information (no Hungarian notation); single letters only for tiny-scope loop counters
- Classes are nouns; methods are verbs

**Code applications:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Variables** | Intention-revealing | `elapsedTimeInDays` not `d` |
| **Booleans** | Predicate phrasing | `isActive`, `hasPermission`, `canEdit` |

### 2. Functions

**Core concept:** Functions should be small, do one thing, and do it well — ideally 4-6 lines, zero to two arguments, one level of abstraction.

**Why it works:** Small single-purpose functions are easy to name, understand, test, and reuse; long functions hide bugs, resist testing, and accumulate responsibilities.

**Key insights:**
- Step-Down Rule: code reads top-down, each function calling the next level of abstraction
- Argument count: zero best, one fine, two acceptable, three+ requires justification
- Flag arguments are a smell — the function does two things; split it

**Code applications:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Long function** | Extract named steps | `validateInput(); transformData(); saveRecord();` |
| **Flag argument** | Split into two functions | `renderForPrint()` / `renderForScreen()` not `render(isPrint)` |

### 3. Comments and Formatting

**Core concept:** A comment is a failure to express yourself in code. When comments are necessary, they explain *why*, never *what*. Formatting creates the visual structure that makes code scannable.

**Why it works:** Comments rot — code changes but comments often don't, creating documentation worse than none. Clean formatting lets developers scan code like a newspaper: headlines first, details on demand.

**Key insights:**
- The best comment is a well-named extracted function
- Acceptable: legal headers, TODOs, public API docs, genuine "why" explanations
- Commented-out code and journal comments: delete — version control remembers

**Code applications:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Explaining "what"** | Replace with better name | `// check if eligible` → `isEligible()` |
| **Explaining "why"** | Keep as comment | `// RFC 7231 requires this header for proxies` |

### 4. Error Handling

**Core concept:** Error handling is a separate concern from business logic. Use exceptions rather than return codes, provide context with every exception, and never return or pass null.

**Why it works:** Return codes clutter the happy path with checks; exceptions separate the two cleanly. Returning null forces null checks on every caller, and one missing check crashes far from the source.

**Key insights:**
- Write the try-catch first — it defines a transaction boundary
- Prefer unchecked exceptions — checked ones violate the Open/Closed Principle
- Define exception classes by the caller's needs, not the failure type

**Code applications:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Null returns** | Empty collection or Optional | `return Collections.emptyList()` not `return null` |
| **Error codes** | Replace with exceptions | `throw new InsufficientFundsException(balance, amount)` |

### 5. Unit Testing

**Core concept:** Tests are first-class code, kept clean with the same discipline as production code. Dirty tests are worse than no tests — they become a liability that slows every change.

**Why it works:** Clean tests are executable documentation and a safety net for refactoring; dirty tests make every modification a fight through incomprehensible test code.

**Key insights:**
- Three Laws of TDD: write a failing test first; only enough test to fail; only enough code to pass
- One concept per test — one logical assertion, not necessarily one assert
- F.I.R.S.T.: Fast, Independent, Repeatable, Self-validating, Timely

**Code applications:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Test structure** | Arrange-Act-Assert | Setup, execute, verify — clearly separated |
| **Test naming** | Scenario + expected behavior | `shouldRejectExpiredToken` not `test1` |

### 6. Code Smells and Heuristics

**Core concept:** Smells are surface indicators of deeper design problems — learn to recognize them quickly and apply targeted refactorings instead of vague "cleanup".

**Why it works:** Smells are heuristics that point toward likely problems without deep analysis, turning code review instinct into specific, repeatable moves.

**Key insights:**
- Function smells: too many arguments, output arguments, flag arguments, dead functions
- General smells: duplication, wrong level of abstraction, feature envy, magic numbers
- Test smells: insufficient coverage, skipped tests, untested boundary conditions and failure paths

**Code applications:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Duplication** | Extract shared logic | Common validation → `validateEmail()` helper |
| **Feature envy** | Move method to the data's class | `order.calculateTotal()` not `calculator.total(order)` |

## Common Mistakes

| Mistake | Why It Fails | Fix |
|---------|-------------|------|
| **Abbreviating names** | Saves seconds writing, costs hours reading | Full descriptive names; IDEs autocomplete |
| **"Clever" one-liners** | Impressive to write, impossible to debug | Expand into readable named steps |
| **Comments instead of refactoring** | Comments rot; code is the truth | Extract a well-named function instead |
| **Catching generic exceptions** | Swallows bugs along with expected errors | Catch specific exceptions; let the rest propagate |

## Quick Diagnostic

| Question | If No | Action |
|----------|-------|--------|
| Can you understand each function without reading its body? | Names don't reveal intent | Rename to describe what it does |
| Are all functions under 20 lines? | Functions do too many things | Extract sub-operations into named helpers |
| Zero commented-out code blocks? | Dead code creating confusion | Delete — version control has history |
| Is error handling separate from business logic? | Try-catch clutters the main flow | Extract handlers; exceptions over return codes |