Clean Code Structure

Purpose

Clean Code rules for functions, classes, formatting, comments, and naming

Rules

FU-001: Functions should be small, blocks within if/else/while should be one line (a function call)

Small functions are easier to read, test, and maintain

FU-002: If you can extract another function with a name that's not a restatement, it does more than one thing

Functions should do one thing at one level of abstraction

FU-003: Zero arguments is best, one is good, two is harder, three should be avoided

Fewer arguments reduce complexity and improve testability

FU-004: Don't create temporal couplings or hidden dependencies between function calls

Implicit ordering creates fragile code

FU-005: Use exceptions, not error codes; extract error handling into separate functions

Error codes force callers to handle errors inline, cluttering logic

CL-001: A class should have one, and only one, reason to change

Single Responsibility Principle — focused classes are maintainable

CL-002: Each method should manipulate one or more instance variables; more variables = higher cohesion

Cohesive classes are self-contained and testable

CL-003: When classes lose cohesion, split them; breaking large functions yields new classes

Cohesion loss signals that a class has grown beyond its purpose

CL-004: Structure classes so changes are isolated; use abstractions at boundaries

Open-Closed Principle — extension without modification

CL-005: Depend on abstract interfaces, not concrete implementations

Dependency Inversion — loose coupling enables testability

FO-001: Code formatting is about communication — the professional developer's first order of business

Code is read far more often than it is written

FO-002: Readability affects maintainability and extensibility long after the original code is changed

Today's formatting decisions become tomorrow's maintenance burden

FO-003: Use an automated tool to apply formatting rules consistently

Manual formatting is inconsistent; automation prevents style debates

FO-004: Team rules — agree on a single formatting style and all members should comply

Consistency across the codebase reduces cognitive load

FO-005: Style and discipline survive even when code does not

Good habits compound across projects

CO-001: Comments do not make up for bad code — clean the code instead of commenting it

Comments are a crutch for unclear code

CO-002: Explain yourself in code — create functions that say the same thing as the comment

Self-documenting code is always current; comments rot

CO-003: Comments lie — they get old, irrelevant, and incorrect as code changes

Comments are not maintained with the same rigor as code

CO-004: Inaccurate comments are far worse than no comments at all

A misleading comment actively harms the reader

CO-005: Only the code can truly tell you what it does — it's the only source of accurate information

Code is the single source of truth for behavior

MENA-001: The name should tell you why it exists, what it does, and how it is used

Intention-revealing names eliminate the need for comments

MENA-002: Don't use names that vary in small ways or that could be confused with platform names

Similar names force the reader to scrutinize differences

MENA-003: Single-letter names only in short methods as loop counters; longer names for larger scopes

Name length should match scope

MENA-004: Classes should have noun or noun phrase names; avoid Manager, Processor, Data

Nouns describe what it IS; vague suffixes hide responsibility

MENA-005: Methods should have verb or verb phrase names with appropriate prefixes

Verbs describe what it DOES

Tags

Overview