Chapter 1 Flashcards — Clean Code
flashcards clean-code philosophy
How did Bjarne Stroustrup define clean code?
?
Clean code is elegant and efficient — it does one thing well. Elegant means pleasing to read. Efficient means it does not waste the reader’s mental effort. These two properties reinforce each other: a function that does one thing is easier to read and less likely to hide inefficiency.
How did Grady Booch define clean code?
?
Clean code reads like well-written prose — it has structure, flow, and purpose. Just as a good paragraph does not introduce a topic and then veer off, a clean function stays focused on its single declared purpose.
How did Dave Thomas define clean code?
?
Clean code can be enhanced by other developers. Maintainability is a first-class attribute. Code that only the original author can understand is not clean — it is a knowledge silo that will eventually be rewritten.
How did Michael Feathers define clean code?
?
Clean code looks like it was written by someone who cares. Care is visible in meaningful names, consistent formatting, and thoughtful error handling. The absence of care is equally visible in cryptic abbreviations, ignored edge cases, and inconsistent style.
What were Ron Jeffries’ five criteria for clean code?
?
No duplication, does one thing, is expressive (names reveal intent), uses tiny abstractions (no unnecessary complexity), and passes all its tests.
How did Ward Cunningham define clean code?
?
Clean code makes the language look like it was made for the problem — each routine is pretty much what you expected. There are no surprises. The reader builds a mental model and the code confirms it at every step.
What is the “productivity curve” for teams that write bad code?
?
Teams with bad code start fast and slow exponentially. Year 1: features ship quickly. Years 2–3: every change requires understanding a growing tangle of interdependencies. Year 4+: productivity approaches zero because more time is spent deciphering existing code than writing new code.
What is the “grand redesign trap”?
?
When productivity collapses from a messy codebase, management authorizes a full rewrite. The new team faces pressure to replicate all existing features while building new ones. They cut corners. Within 2–3 years, the new system is the next mess. The cycle repeats because the culture, not just the code, was the problem.
What is the total cost of owning a mess?
?
Every messy line of code taxes every future reader — the developer fixing a bug next month, the new hire onboarding in six months, and yourself six months later. The cost compounds: misunderstanding causes bugs, bugs require more reading, each “quick fix” adds more mess.
What is the reading-to-writing ratio for code?
?
Developers spend roughly 10x more time reading code than writing it. This makes readability the single most important performance concern — not execution speed, not cleverness.
What is the WTFs per minute metric?
?
A humorous but accurate measure of code quality: the number of times a reviewer says “WTF?!” per minute during a code review. Clean code produces 0 WTFs. Bad code — with cryptic names, mixed concerns, and magic numbers — produces many. Quality is inversely proportional to WTFs per minute.
What causes WTFs to accumulate during code review?
?
Names that do not reveal intent (d, tmp, flag), functions that do multiple unrelated things, comments that contradict the code, copy-pasted logic that should be abstracted, magic numbers without explanation (e.g., if (status == 4)), and over-engineered abstractions wrapping trivial logic.
What is the Boy Scout Rule applied to code?
?
“Always leave the campground cleaner than you found it.” Whenever you open a file to make a change, leave it slightly better: rename one obscure variable, extract one block into a named method, delete one dead code path. Small improvements compound over time and prevent codebase decay without requiring disruptive rewrites.
Why is “we’ll clean it up later” almost always a lie?
?
Later rarely comes. Teams under delivery pressure always have the next feature to ship. Without the Boy Scout Rule enforcing continuous micro-improvements, cleanup gets permanently deferred. The only reliable strategy is to improve incrementally on every visit to a file.
What does “we are authors” mean in the context of clean code?
?
Code is written for human readers, not machines. A novelist writes for readers, not the printing press. Professional developers bear the same responsibility: writing obscure code is a failure of craft, not just an aesthetic choice. The compiler accepts anything; humans need clarity.
What professional responsibility does writing clean code imply?
?
Developers should refuse to accept pressure to ship permanently messy code. “We’ll refactor later” is acceptable only if followed by actual refactoring. Shipping deliberately obscure code as a permanent state is a professional failure — equivalent to a surgeon leaving instruments inside a patient because the operation was fast.
Why do full rewrites often reproduce the original mess?
?
The new team faces the same incentive structure: delivery pressure, incomplete understanding of requirements, time constraints. Without a cultural commitment to clean code principles, the rewrite cuts the same corners. The mess was a symptom of culture, not just codebase age.
What does “code is written for readers, not machines” imply about optimization?
?
Readability comes first. Optimize for the human reader before optimizing for execution speed. Premature micro-optimization that obscures intent is the wrong trade-off in almost every case. Readable code is also easier to correctly optimize when profiling reveals it is necessary.
What is the difference between a clean codebase and a clean function?
?
A clean function does one thing, has a good name, and is short. A clean codebase is the aggregate of clean functions, classes, and modules — plus consistent formatting, minimal duplication, and shared conventions. Clean code at scale requires the same discipline applied consistently, not just in high-visibility places.
How does the productivity crash differ from a bug or performance issue?
?
The productivity crash is structural, not symptomatic. You cannot fix it by patching individual bugs. It is caused by accumulated complexity across the entire codebase — every function that does too much, every name that misleads, every duplicated logic block. Only systematic improvement (Boy Scout Rule + discipline) reverses it.
What distinguishes clean code from merely “working” code?
?
Working code passes tests and satisfies requirements. Clean code also communicates — names reveal intent, structure shows relationships, and a new reader can understand it without a guided tour from the author. Many codebases work perfectly and are also complete disasters to maintain.
What does Ward Cunningham’s definition imply about naming?
?
Names should be so accurate that each routine is pretty much what you expected. If you open a method called calculateMonthlyPayment() and it also sends an email, it violates Cunningham’s definition — the reader is surprised. Surprising code is, by definition, not clean.
How does bad code affect developer morale?
?
Developers who work in bad code daily become demoralized. Progress is slow and frustrating. Good engineers leave for codebases where they can be productive. The remaining engineers are less likely to have the skills or motivation to improve the code, accelerating its decline.
What is the practical takeaway from the reading-to-writing ratio for code reviews?
?
Code review time is dominated by reading and understanding, not by evaluating correctness. Optimizing for readability directly reduces review time, accelerates onboarding, and reduces the cost of every code change. Readable code is not a soft quality — it has measurable business value.
When is it acceptable to write messy code?
?
In short-lived prototypes and exploratory spikes that are explicitly intended to be discarded, not promoted to production. The risk is that “temporary” code regularly survives into production. The rule: if the code will be read by another developer or maintained for more than a week, clean code standards apply.
What is the relationship between clean code and testability?
?
Clean code is almost always more testable than messy code. Functions that do one thing can be unit tested in isolation. Mixed-concern functions require complex setup, mocking, and teardown — and still only test the whole bundle, not individual concerns. Testability is a useful proxy for clean design.
Total Cards: 26
Review Time: ~20 minutes
Priority: HIGH
Last Updated: 2026-04-14