Glossary

Abstraction — A simplified view of an entity that omits unimportant details. In a module, the interface is the abstraction (Ch 4)

Change amplification — A symptom of complexity: a seemingly simple change requires edits in many places (Ch 2)

Classitis — The mistaken view that “classes are good, so more classes are better,” which produces many shallow classes (Ch 4)

Cognitive load — A symptom of complexity: how much a developer needs to know to complete a task (Ch 2)

Complexity — “anything related to the structure of a software system that makes it hard to understand and modify the system” (Ch 2)

Complexity formula — C = Σ c_p t_p: each part’s complexity weighted by the fraction of developer time spent on it (Ch 2)

Context object — One object per system instance holding global state (configuration, shared subsystems, counters), referenced from major objects. The author’s usual fix for pass-through variables (Ch 7)

Critical path — The minimum code that must run in the most common case; the target when redesigning for performance (Ch 20)

Cross-module comment — Documentation of a design decision that spans several modules, placed where developers will find it or in a designNotes file (Ch 13, Ch 16)

Decorator (wrapper) — An object with the same API as the object it wraps, adding one feature. Tends to be shallow (Ch 7)

Deep module — A module that hides a lot of functionality behind a simple interface (Ch 4)

Define errors out of existence — Change an API’s semantics so the error case can’t occur, as in Tcl’s unset, which “should ensure that a variable no longer exists” (Ch 10)

Dependency — A relationship where code “cannot be understood and modified in isolation” (Ch 2)

Design it twice — Sketch several radically different designs for each major decision before choosing (Ch 11)

designNotes — A central file of labeled sections for cross-module issues, with short pointers from the code (Ch 13)

Exception aggregation — Handling many exceptions with one handler, usually high in the call stack (Ch 10)

Exception masking — Handling an exceptional condition at a low level so higher levels never see it (Ch 10)

False abstraction — An abstraction that omits important details, so it looks simpler than it is (Ch 4, Ch 6)

Formal interface — The parts of an interface stated in code and checkable by the language, such as signatures (Ch 4)

Fundamental fix — A performance change in approach, such as a cache, a different algorithm, or kernel bypass (Ch 20)

General-purpose (somewhat) — Functionality reflects current needs, but the interface doesn’t (Ch 6)

Implementation inheritance — A parent class supplies method code to subclasses; reduces duplication but leaks state (Ch 19)

Informal interface — Behavior and usage constraints that only comments can describe (Ch 4)

Information hiding — Encapsulating design decisions in a module’s implementation so they don’t appear in its interface (Ch 5)

Information leakage — A design decision reflected in several modules; includes “back-door” leakage through shared knowledge (Ch 5)

Interface — “everything that a developer working in a different module must know in order to use the given module” (Ch 4)

Interface comment — The comment before a class or method that defines its abstraction: behavior, arguments, return value, side effects, exceptions, and preconditions (Ch 13)

Interface inheritance — Subclasses implement a shared set of signatures; more implementations make the interface deeper (Ch 19)

Invariant — A property of a variable or structure that is always true (Ch 13, Ch 17)

Module — Any unit of code with an interface and an implementation: class, method, function, subsystem, or service (Ch 4)

Naturally efficient — A design as simple as the slow alternative but faster, such as a hash table instead of an ordered map (Ch 20)

Obscurity — A cause of complexity: important information is not obvious (Ch 2)

Obvious code — Code a reader can understand quickly, with correct first guesses (Ch 2, Ch 18)

Pass-through method — A method that does little except call another method with a similar signature (Ch 7)

Pass-through variable — A variable passed down a chain of methods that don’t use it (Ch 7)

Precision (comments) — Lower-level comment detail: units, boundaries, null meaning, ownership, invariants (Ch 13)

Pull complexity downwards — Handle complexity inside a module rather than exposing it to users (Ch 8)

Red flag — A sign that code is probably more complicated than it needs to be (Ch 1, Ch 21)

Shallow module — A module whose interface is complicated relative to its functionality (Ch 4)

Strategic programming — Making a great design the primary goal, investing 10–20% of time in it (Ch 3)

Tactical programming — Focusing on getting the current task working, accepting small complexities (Ch 3)

Tactical tornado — A prolific programmer who works totally tactically and leaves a mess for others (Ch 3)

Temporal decomposition — Structuring code by the order in which operations happen, which causes leakage (Ch 5)

Test-driven development — Writing unit tests before code; the author calls it tactical, except for bug fixes (Ch 19)

Unknown unknowns — The worst symptom of complexity: you can’t tell what code to change or what you need to know (Ch 2)

Zero tolerance — Refusing even small increments of complexity, because complexity accumulates (Ch 2, Ch 3)