Writing code the next person can change: naming, decomposition, refactoring, and the review habits that keep it that way.
14 articles
Listed inCode ReviewCode Crafton
What a reviewer should look for, how fast to respond, and the standard for approving a change that is good but not perfect.
Listed inRefactoringCode Crafton
Every named refactoring with its mechanics — the step-by-step sequence that keeps the code working the whole way through.
Listed inAbstraction vs IndirectionCode Crafton
Rich Hickey separates simple from easy, and names the complecting that makes a codebase expensive to change.
Listed inCoupling and CohesionCode Crafton
The two properties that predict how expensive your next change will be.
Listed inRefactoringCode Crafton
Behaviour-preserving change under a test suite, in steps small enough to abandon at any point.
Listed inWorking with Legacy CodeCode Crafton
Characterisation tests, seams, and changing code you do not understand without breaking it.
Listed inFunctions and DecompositionCode Crafton
One job per function, argument count as a design smell, and when splitting makes things worse.
Listed inComments and DocumentationCode Crafton
Comment the why, not the what — and the handful of cases where the what genuinely needs saying.
Listed inLinting and FormattingCode Crafton
Automating every argument a tool can settle, so review time goes to the parts that matter.
Listed inNamingCode Crafton
The cheapest documentation there is, and the one refactor that pays back every single time.
Listed inAbstraction vs IndirectionCode Crafton
When a layer removes work and when it only moves it, plus the rule of three for extracting one.
Listed inCode ReviewCode Crafton
Reviewing for correctness and design rather than style, and giving feedback that lands.
Listed inSOLID and Its CriticsCode Crafton
What each letter is actually for, and where applying it mechanically produces worse code.
Listed inCode SmellsCode Crafton
The recurring shapes that signal a design problem, and the refactor each one points at.