Dennis Ritchie on the priorities of && || vs. == etc. (1982)

Original Article ↗ Hacker News Discussion ↗

Operator precedence for boolean and bitwise operators in C and related languages—particularly `&&`, `||`, `&`, `|`, and `==`—is scrutinized as a long-standing source of subtle bugs and confusion. Commenters examine the historical reasons Dennis Ritchie gave for choices like making `&` lower precedence than `==`, and contrast them with mathematical intuitions from Boolean algebra, set theory, and probability. Many advocate using explicit parentheses or language designs that restrict ambiguous expressions, noting that newer languages and linters increasingly favor clarity over relying on memorized precedence rules.

Main confusion: precedence of logical operators

  • Many admit they don’t reliably remember && vs || (and often SQL’s AND/OR), and choose to always parenthesize mixed expressions.
  • Others argue developers should simply learn the rules, comparing &&/|| precedence to */+.
  • Several note that even those who know the rules get bitten when switching languages where precedence differs (e.g., shells).

Arithmetic, Boolean algebra, and mnemonics

  • Multiple comments connect && to multiplication and || to addition for 0/1 values: product = AND, (saturated) sum = OR.
  • Others prefer set theory: && as intersection, || as union, with distributive laws mirroring Boolean algebra.
  • Some point out XOR aligns more cleanly with addition in mod‑2 arithmetic, but the analogy still helps remember relative precedence.

Parentheses as style and safety

  • Strong camp in favor of explicit parentheses for any nontrivial Boolean expression, even if precedence is known.
  • Arguments:
    • Easier for future readers and code reviewers.
    • Prevents subtle bugs when expressions are edited or copied.
    • Linters that warn on a && b || c–style expressions are welcomed after real‑world bugs.
  • Counter‑arguments:
    • Excess parentheses add noise and cognitive overhead; they should indicate overrides, not restate defaults.
    • Unnecessary == true / == false and over‑parenthesizing are seen as signs of weak understanding.

C’s bitwise vs comparison precedence (“the real” Ritchie topic)

  • Clarification that the original article is mainly about why bitwise &/| have lower precedence than == and friends, not about && vs ||.
  • Historically, & was used for logical AND before && existed, so a==b & c==d needed to behave logically; that choice later made expressions like addr & mask == 0 parse unintuitively as addr & (mask == 0).
  • Commenters agree this is widely considered a design mistake but was preserved for backward compatibility.

Language design alternatives

  • Some languages require parentheses when mixing different infix operators (Ada for logical ops; Pony, partially Zig, WGSL, Carbon-style approaches).
  • Others avoid or minimize precedence (Smalltalk left‑to‑right; Lisp/Scheme via prefix notation).
  • Strictly typed or newer languages adjust precedence (Go/Rust/Swift, Python) or merge bitwise/logical operators in controlled ways (e.g., Sail), often with short‑circuiting on booleans.