Designing classes and interfaces in TypeScript. Explains information hiding (encapsulation) / single responsibility / keeping classes small / preferring composition over inheritance with Bad / Good comparisons. Also covers the ideas of cohesion and coupling.
A practical guide to writing clean, maintainable TypeScript. It explains step by step why each rule matters and how to apply it. A roadmap that organizes design principles for leveraging the type system across 13 articles.
The art of comments in TypeScript. The core principle that Why goes in comments and What goes in code, plus patterns to keep stale comments from contradicting the code during maintenance. Also covers using JSDoc and writing self-documenting code.
Best practices for conditional branching in TypeScript. A guide to keeping nesting shallow with early returns, discriminated unions and exhaustiveness checks, and reducing if statements with polymorphism, explained with Bad / Good comparisons.
The five principles pull against each other. Push splitting and a change touches more files; interpose an abstraction and it takes more steps to trace what actually runs. This chapter covers how to decide when they conflict, and modern criticism of SOLID itself.
Best practices for designing functions in TypeScript. Compares single responsibility / pure functions / early return / minimizing arguments / avoiding side effects / the DRY principle with Bad / Good examples. Also covers clarifying input and output with type annotations.
Best practices for defining variables in TypeScript. Explains turning magic numbers / magic characters into constants, choosing between const and let, minimizing scope, and not giving a variable multiple meanings, using Bad / Good comparisons.
A hub for the domain covering how code is written and structured. It spans everyday decisions such as naming and splitting functions, a closer look at the SOLID principles, and a rereading of the GoF patterns in modern TypeScript.
How to choose between forEach / map / filter / reduce and the difference between for...of and for...in. Explains array-processing best practices that make intent clear with higher-order functions, using Bad / Good comparisons.
Naming conventions in TypeScript, Part 1. Explains how to choose among the four case conventions (kebab, snake, Pascal, camel) and how to name variables, booleans, and constants, using Bad / Good comparisons. The gateway to naming well, so the code itself becomes documentation.
Naming conventions in TypeScript, Part 2. Explains naming functions with verb patterns such as get / set / calculate, functions that return a boolean, suffix patterns for class names, and the criteria for not making method names redundant, using Bad / Good comparisons.
Naming conventions in TypeScript, Part 3. Covers principles that improve naming quality, such as pronounceable names, plural forms for arrays, unifying synonyms, contrasting words, avoiding meaningless words, and criteria for abbreviation, plus a comprehensive exercise and a quick reference summary.
The five SOLID principles were not born at the same time. Read the original text Martin published in 2000 and what you find are four principles of class design and six of package design, with SRP not among them. This chapter covers what the acronym hid.
Explains the five SOLID principles of object-oriented design (single responsibility / open-closed / Liskov substitution / interface segregation / dependency inversion) with TypeScript examples. Deepen your understanding with a Bad / Good comparison for each principle.
A seven-chapter series that digs into the five SOLID principles across three layers, why you follow them, when it's OK to break them, and how they get misused. Each chapter goes to the original text of the principle and covers how it is reassessed today.
A recap of all 11 articles in the Clean Code Guide (TypeScript). It visualizes the big picture of naming, functions, type safety, object orientation, and the SOLID principles as a mindmap, and serves as a checklist to use while coding.
DIP, DI, and IoC are separate concepts. Passing dependencies in from outside does not by itself invert anything. This chapter confirms from the original text what actually inverts, and which module the abstraction should belong to.
ISP has two motivations, avoiding recompilation and a design concern, and the former does not exist in TypeScript in its original form. In a structural type system you can satisfy ISP without carving out an interface.
LSP says a derived type must be substitutable for its base type, but the criterion for deciding substitutability lies in the contract. This chapter covers the four items the original text set out, precondition, postcondition, invariant, and history property, and how far the type checker is actually looking.
OCP asks you to prepare extension points in advance, but misread the direction of extension and you are left with a wrong abstraction. This chapter confirms what the original text named as the means of achieving it, and covers how to judge its conflict with YAGNI.
SRP's definition of "one reason to change" is subjective, and the granularity of the split shifts with every reader. This chapter covers what Martin meant when he later stated that this principle is about people, and what you lose when you split too far.
Best practices for using the TypeScript type system effectively. Explains avoiding any, choosing between unknown and never, generics, utility types, and narrowing with type guards, using Bad / Good comparisons.