---
name: concise-code
description: "Clean Code Quick Reference. Provides quick reference for 'Clean Code' by Robert C. Martin (Uncle Bob), including naming rules, function design, comments, formatting, testing, and code smells. Keywords: clean code, naming, functions, refactoring, code smells, best practices."
---

## Overview

Quick reference guide for writing clean, maintainable code based on "Clean Code" by Robert C. Martin.

## Applicable Scenarios

**When to use:**
- Naming variables, functions, or classes
- Designing functions and their parameters
- Deciding whether to write comments
- Formatting code
- Writing unit tests
- Refactoring messy code
- Reviewing code for cleanliness

**When NOT to use:**
- Learning programming basics (assumes you know how to code)
- Language-specific syntax questions
- Algorithm design
- System architecture decisions

**Trigger keywords**: clean code, naming, functions, refactoring, code smells, best practices, uncle bob

## Prerequisites

None. This is a reference skill providing guidelines and checklists.

## Core Capabilities

### Capability 1: Naming Guidelines
How to create meaningful, clear names for variables, functions, and classes.

### Capability 2: Function Design
Rules for writing small, focused functions with proper parameters.

### Capability 3: Comments Strategy
When to write comments and when to avoid them.

### Capability 4: Code Formatting
Vertical and horizontal formatting rules for readability.

### Capability 5: Testing Principles
TDD laws and F.I.R.S.T. principles for unit testing.

### Capability 6: Code Smells Detection
Quick checklist for identifying and fixing common code problems.

## Quick Reference

### The Boy Scout Rule
> Leave the campground cleaner than you found it.

### Simple Design Rules (Priority Order)
1. Run all tests
2. Eliminate duplication (DRY)
3. Increase expressiveness
4. Minimize classes and methods

---

## Chapter 2: Meaningful Names

### Naming Rules

| ✅ Do | ❌ Don't |
|-------|----------|
| Reveal intent | Use misleading names |
| Use pronounceable names | Use abbreviations |
| Use searchable names | Use single-letter variables (except loops) |
| Class names are nouns | Class names as verbs |
| Method names are verbs | Unclear method names |
| One word per concept | Mix fetch/retrieve/get |
| Add meaningful context | Add gratuitous context |

### Quick Check
- [ ] Name needs no comment to explain
- [ ] Name can be pronounced
- [ ] Name can be searched
- [ ] Same concept uses same word

---

## Chapter 3: Functions

### Function Rules

| Rule | Standard |
|------|----------|
| Small | < 20 lines |
| Do one thing | Only one responsibility |
| One abstraction level | No mixing high/low level |
| Arguments | 0 best, 1 okay, 2 acceptable, avoid 3+ |
| No side effects | Don't do hidden things |
| Command/Query separation | Do OR ask, not both |

### Argument Guidelines
- **Unary**: Ask question (isFileExists) or operate (file.open())
- **Flag arguments**: Split into two functions
- **Binary**: Try to make unary
- **Many args**: Use parameter object

---

## Chapter 4: Comments

### Good Comments (Write These)
- Legal information
- Informative explanations
- Intent explanation
- Warnings about consequences
- TODO markers
- Public API documentation

### Bad Comments (Avoid These)
- Mumbling (only you understand)
- Redundant with code
- Misleading
- Mandated by policy
- Journal/history (use version control)
- Noise (// default constructor)
- Commented-out code (delete it)

### Golden Rule
> Use code to explain. Comments cannot beautify bad code.

---

## Chapter 5: Formatting

### Vertical Formatting
- Separate concepts with blank lines
- Related code stays close
- Variable declarations near usage
- Called functions below callers

### Horizontal Formatting
- 80-120 characters per line
- Spaces separate weakly related items
- Indentation shows hierarchy

---

## Chapter 6: Objects and Data Structures

### Law of Demeter
> A module should not know internal details of objects it manipulates.

**Avoid Train Wrecks:**
```java
// Bad
String path = ctxt.getOptions().getScratchDir().getAbsolutePath();

// Good
String path = ctxt.getScratchDirAbsolutePath();
```

---

## Chapter 7: Error Handling

### Checklist
- [ ] Use exceptions, not return codes
- [ ] Write try-catch-finally first
- [ ] Use unchecked exceptions
- [ ] Provide context with exceptions
- [ ] Don't return null
- [ ] Don't pass null

---

## Chapter 9: Unit Testing

### Three Laws of TDD
1. No production code without failing test first
2. Write only enough test to fail
3. Write only enough code to pass test

### F.I.R.S.T. Principles
| Letter | Meaning |
|--------|---------|
| F | Fast |
| I | Independent |
| R | Repeatable |
| S | Self-validating |
| T | Timely |

---

## Chapter 10: Classes

### Key Principles
- **SRP**: One reason to change
- **OCP**: Open for extension, closed for modification
- **Cohesion**: Methods operate on class variables
- **Small**: Class name describes its responsibility

---

## Chapter 17: Code Smells

### Naming
- [ ] Descriptive names
- [ ] Appropriate abstraction level
- [ ] Standard nomenclature
- [ ] Unambiguous
- [ ] Longer names for larger scopes

### Functions
- [ ] Does one thing
- [ ] One abstraction level
- [ ] Name describes behavior
- [ ] Few arguments

### Tests
- [ ] Adequate coverage
- [ ] Fast execution
- [ ] Independent
- [ ] Boundary conditions tested

---

## Decision Tree

```
Start writing code
    |
    ▼
Name clear? ──No──▶ Rename
    |Yes
    ▼
Function does one thing? ──No──▶ Split
    |Yes
    ▼
Function small (<20 lines)? ──No──▶ Extract
    |Yes
    ▼
Duplicate code? ──Yes──▶ Eliminate
    |No
    ▼
Needs comments? ──Yes──▶ Use code instead
    |No
    ▼
Clean code! Commit.
```

---

## Output Format

When helping with clean code, provide:

```markdown
## Clean Code Analysis

### Issue Identified
[Specific problem with the code]

### Relevant Rule
[Which clean code principle applies]

### Suggested Improvement
```
[Improved code example]
```

### Checklist
- [ ] Naming: [assessment]
- [ ] Function size: [assessment]
- [ ] Single responsibility: [assessment]
- [ ] Comments: [assessment]
- [ ] Tests: [assessment]
```

---

## References

- **Book**: Clean Code: A Handbook of Agile Software Craftsmanship
- **Author**: Robert C. Martin (Uncle Bob)
- **Publisher**: Prentice Hall

## Notes

- Guidelines are principles, not absolute rules
- Context matters—use judgment
- The goal is maintainable, readable code