code-complexity

# Code complexity — keeping a unit comprehensible Complexity is not how clever the code is. It is how much you must hold in your head to change one line safely. It accumulates by increments that each look acceptable, which is why it is never one bad commit's fault and always everyone's problem. ## The two symptoms worth memorising **Change amplification** — one decision, many edits. If changing a timeout means editing five files, that decision was not encapsulated anywhere. **Cognitive load** — how much you must know to be safe. A function that is correct only if you know that the caller already took a lock has exported its complexity to everyone who reads it. Both are properties of the *interface*, not the implementation. Which gives the rule: ## Deep over shallow A module's value is `functionality it provides ÷ interface you must learn`. Deep = small interface, substantial behaviour behind it. Shallow = large interface, little behind it. - A pass-through method that only calls one other method with the same arguments is negative value: it adds an interface without adding behaviour. - "One class per concept, many tiny classes" is not automatically good. Many shallow classes cost more total interface than a few deep ones. - The right question is never "is this class small?" but "how much do I need to know to use it?" ## Information hiding — and its inverse Every design decision that might change should be known to exactly one module. The inverse — **informatio...