"Clean" Code, Horrible Performance (2023)
Critiques of “Clean Code” style object‑oriented design argue that its emphasis on tiny methods, deep polymorphic hierarchies, and hidden internals can lead to poor performance by fighting CPU caches and adding indirection. Commenters counter that these patterns were meant to improve readability and maintainability, and that real bottlenecks often lie elsewhere (e.g., network I/O, heavy frameworks) rather than in virtual dispatch. The broader theme is that coding “principles” like DRY, small functions, and interfaces are useful only when applied with judgment to specific domains and constraints, rather than followed as dogma.
Clean Code’s value and limitations
- Many see the book as useful scaffolding for early-career developers needing structure.
- Others argue it teaches bad or narrow practices (“clean OOP code” only) and is actively harmful, even for beginners.
- Common complaint: it encourages dogmatic rules (tiny functions, polymorphism, shunning comments) and a preachy framing that labels dissent as “unprofessional.”
- Some mention a newer edition intended to address misinterpretations, but its quality is described as unclear.
Performance vs. maintainability
- Core debate: “clean” abstractions (especially OO and polymorphism) often hurt performance but may ease maintenance and extensibility.
- Several argue performance should be driven by measurement: write simple code, then optimize hotspots.
- Others counter that certain styles (heavy runtime polymorphism, deep abstraction layers) can leave a system globally slow, not just in hotspots.
OOP, polymorphism, and alternatives
- Many note the classic example uses runtime polymorphism and vtables, which are known to be slower than flat data and switches, especially in tight loops.
- Some stress modern compilers inline small functions well; dynamic dispatch is the main cost, not “clean code” per se.
- Alternatives mentioned: sum types plus exhaustive matches, procedural dispatch (switches or tables), static polymorphism, and zero-cost abstractions in newer languages.
Function size and structure
- Strong disagreement on function length rules.
- Some like very small, single-purpose functions for clarity; others find that style fragmented and harder to follow.
- Long but linear functions can be acceptable if they do “one coherent thing”; artificial splitting can harm readability.
Principles vs. dogma
- Several commenters emphasize that principles like DRY, SRP, and “clean code” are low-level tools with trade‑offs, not universal laws.
- Over‑application leads to dead coupling, fragmentation, low cohesion, and performance problems.
- Consensus theme: use judgment; context (domain complexity, performance needs, team size, extensibility) should drive design.
Critiques of the article and examples
- Some think the critique attacks a toy, non-performance-focused example and thus amounts to a strawman.
- Others reply that the example came from the book itself and concretely demonstrates how the promoted style can degrade performance, which is a valid point even if the original intent was pedagogical.
Broader ecosystem complaints
- Multiple comments suggest that, in everyday apps, the worst performance issues come less from OO patterns and more from heavy stacks (e.g., Electron, “web tech” on desktop) and network latency, not from function size or polymorphism alone.