Principle: Make invalid states unrepresentable

Code has runtime checks for combinations of fields that should never occur, leading to defensive programming throughout the codebase.

Use the type system to make invalid states impossible to construct:

// BAD: Many invalid states possible
interface Request {
  status: 'pending' | 'loading' | 'success' | 'error';
  data?: ResponseData;   // Only valid when success
  error?: Error;          // Only valid when error
  progress?: number;      // Only valid when loading
}
// Can have status='error' with data set, or status='success' with error set

// GOOD: Invalid states are unrepresentable
type Request =
  | { status: 'pending' }
  | { status: 'loading'; progress: number }
  | { status: 'success'; data: ResponseData }
  | { status: 'error'; error: Error };

// Another example:
// BAD: email and phone both optional
interface Contact {
  email?: string;
  phone?: string;
  // What if both are missing?
}

// GOOD: at least one is required
type Contact =
  | { email: string; phone?: string }
  | { email?: string; phone: string };

Applies to any language with sum types: TypeScript discriminated unions, Rust enums, Haskell ADTs, Kotlin sealed classes.

Every impossible state you allow in your types requires a runtime check, an error message, a test, and documentation. Eliminating them at the type level removes all of that.

Designing data models and state machines