Clean Code

# Clean Code Skill

This skill embodies the principles of "Clean Code" by Robert C. Martin (Uncle Bob). Use it to transform "code that works" into "code that is clean."

🧠 Core Philosophy

> "Code is clean if it can be read, and enhanced by a developer other than its original author." — Grady Booch

When to Use

Use this skill when:

- **Writing new code**: To ensure high quality from the start.

- **Reviewing Pull Requests**: To provide constructive, principle-based feedback.

- **Refactoring legacy code**: To identify and remove code smells.

- **Improving team standards**: To align on industry-standard best practices.

1. Meaningful Names

- **Use Intention-Revealing Names**: `elapsedTimeInDays` instead of `d`.

- **Avoid Disinformation**: Don't use `accountList` if it's actually a `Map`.

- **Make Meaningful Distinctions**: Avoid `ProductData` vs `ProductInfo`.

- **Use Pronounceable/Searchable Names**: Avoid `genymdhms`.

- **Class Names**: Use nouns (`Customer`, `WikiPage`). Avoid `Manager`, `Data`.

- **Method Names**: Use verbs (`postPayment`, `deletePage`).

2. Functions

- **Small!**: Functions should be shorter than you think.

- **Do One Thing**: A function should do only one thing, and do it well.

- **One Level of Abstraction**: Don't mix high-level business logic with low-level details (like regex).

- **Descriptive Names**: `isPasswordValid` is better than `check`.

- **Arguments**: 0 is ideal, 1-2 is okay, 3+ requires a very strong justification.

- **No Side Effects**: Functions shouldn't secretly change global state.

3. Comments

- **Don't Comment Bad Code—Rewrite It**: Most comments are a sign of failure to express ourselves in code.

- **Explain Yourself in Code**:

```python

# Check if employee is eligible for full benefits

if employee.flags & HOURLY and employee.age > 65:

```

vs

```python

if employee.isEligibleForFullBenefits():

```

- **Good Comments**: Legal, Informative (regex intent), Clarification (external libraries), TODOs.

- **Bad Comments**: Mumbling, Redundant, Misleading, Mandated, Noise, Position Markers.

4. Formatting

- **The Newspaper Metaphor**: High-level concepts at the top, details at the bottom.

- **Vertical Density**: Related lines should be close to each other.

- **Distance**: Variables should be declared near their usage.

- **Indentation**: Essential for structural readability.

5. Objects and Data Structures

- **Data Abstraction**: Hide the implementation behind interfaces.

- **The Law of Demeter**: A module should not know about the innards of the objects it manipulates. Avoid `a.getB().getC().doSomething()`.

- **Data Transfer Objects (DTO)**: Classes with public variables and no functions.

6. Error Handling

- **Use Exceptions instead of Return Codes**: Keeps logic clean.

- **Write Try-Catch-Finally First**: Defines the scope of the operation.

- **Don't Return Null**: It forces the caller to check for null every time.

- **Don't Pass Null**: Leads to `NullPointerException`.

7. Unit Tests

- **The Three Laws of TDD**:

1. Don't write production code until you have a failing unit test.

2. Don't write more of a unit test than is sufficient to fail.

3. Don't write more production code than is sufficient to pass the failing test.

- **F.I.R.S.T. Principles**: Fast, Independent, Repeatable, Self-Validating, Timely.

8. Classes

- **Small!**: Classes should have a single responsibility (SRP).

- **The Stepdown Rule**: We want the code to read like a top-down narrative.

9. Smells and Heuristics

- **Rigidity**: Hard to change.

- **Fragility**: Breaks in many places.

- **Immobility**: Hard to reuse.

- **Viscosity**: Hard to do the right thing.

- **Needless Complexity/Repetition**.

🛠️ Implementation Checklist

- [ ] Is this function smaller than 20 lines?

- [ ] Does this function do exactly one thing?

- [ ] Are all names searchable and intention-revealing?

- [ ] Have I avoided comments by making the code clearer?

- [ ] Am I passing too many arguments?

- [