Don't use booleans (2019)

Original Article ↗ Hacker News Discussion ↗

Overall reception of the article

  • Many agree the title is clickbait but the central idea is sound: naive boolean use leads to confusing APIs and hard-to-extend code.
  • Others see the advice as too absolutist; booleans are fine in many places, and “never use booleans” could push beginners into needless complexity.

When booleans cause trouble

  • Multiple boolean parameters (especially flags) degrade readability: foo(true, false, true) is hard to understand and easy to misorder.
  • As features accrete, one flag becomes two, then three, etc., creating tangled conditionals and “boolean blindness.”
  • Interdependent flags (e.g., arg3 only valid if arg1 is true) are hard to model safely with plain booleans.

Enums and richer types

  • Enums (or sum types / tagged unions) make invalid states unrepresentable and document meaning explicitly.
  • They upgrade better when a “two-state” assumption grows to more cases (e.g., multiple error reasons, more invoice types).
  • Some worry about overhead: extra types, imports, and verbosity; others argue this is minor compared to debugging confusing flags.

Named / keyword parameters and options objects

  • Many see named parameters / keyword arguments as the main cure: RaiseInvoice(taxInvoice: false, sendEmail: true).
  • In languages without them, common patterns include:
    • Passing a single “options” struct/object.
    • Using language features like Python’s keyword-only args or JS/TS “options objects.”
  • Some note you can’t force callers to use names, so APIs can still be misused.

Language-specific patterns and nuances

  • JS/TS: options objects and string-literal unions are popular; opinions split on TypeScript enum vs union-of-strings.
  • Python: Literal[...] and Enum plus type checkers; keyword-only params help.
  • C/C++/Go: options structs and designated initializers used to simulate named args.
  • Rust/Haskell/ML: strong enum/sum-type culture; related debates about Option<Enum> vs Enum with a Missing variant.

Broader design themes

  • Core principle: model domain concepts explicitly instead of “just another bool.”
  • Booleans remain appropriate for truly binary, obvious cases (e.g., “active/inactive”), but many argue even there, separate methods or small enums can be clearer.