📖 Business
Biz - Clean Functions
Robert C. Martin's rules for writing functions that are small, focused, and readable. The central argument: a function should do one thing, do it well, and do it only. Functions are the verbs of your code — they describe what happens — and if your verbs are muddled, your story is incomprehensible. Martin uses the "newspaper metaphor": code should read like a well-organized article — headline at the top (function name), abstract (first lines), then progressively deeper detail as you scroll down.
2
Minutes
2
Concepts
+45
XP
1
How It Works
The seven rules of clean functions:
- Do one thing. If a function does multiple things, extract each into its own function. A function does "one thing" if you cannot meaningfully extract another function from it.
- One level of abstraction per function. Don't mix high-level policy ("getUserPermissions") with low-level detail ("parseJWTBase64String") in the same function. This is the Stepdown Rule: each function should lead you naturally to the next level of abstraction.
- Read top-to-bottom like a story. Functions should be ordered so that each one calls the next, creating a narrative flow. The reader should never need to scroll up to understand what's happening.
- Minimal arguments. Zero is ideal, one is good, two is tolerable, three requires justification. Each argument increases cognitive load and testing complexity (2 boolean args = 4 test cases).
- No side effects. A function named
checkPasswordshould not also initialize a session. Side effects are lies — they promise one thing and do another. - Command-Query Separation. A function should either do something (change state) or answer something (return information), never both.
setAttributeshould not also return the old value. - Prefer exceptions to error codes. Error codes force deeply nested if-else chains and require the caller to handle errors immediately. Exceptions allow the happy path to read cleanly.