The Montreal problem: Why programming languages need a style czar

Role and value of style consistency

• Many argue basic consistency (indentation, brace placement, avoiding giant style-only diffs) clearly helps readability and maintenance, especially in large teams.
• Others say style has little impact compared to design, naming, and architecture; you can write unreadable yet perfectly “styled” code, and good engineers should read any reasonable style.
• Some note that inconsistent style forces extra cognitive effort (“is this different for a reason or just style?”) and that style violations often co-occur with bugs.

Arguments for automated formatting and style guides

• Supporters see auto-formatters (gofmt, rustfmt, Black, etc.) as a way to:
  • Eliminate bikeshedding and PR nitpicks.
  • Make codebases visually uniform and faster to scan.
  • Let humans focus reviews on logic, not whitespace.
• Language-provided, non-configurable or narrowly-configurable formatters are praised for ending unproductive debates.
• Linters and “idiomatic” guidance are viewed as especially valuable in large, long-lived codebases.

Arguments against rigid standards and “style czars”

• Some strongly dislike style guides and rigid tooling, seeing them as arbitrary impositions that don’t guarantee readability and can even harm it.
• Complaints include:
  • Formatters destroying deliberate alignment, “tables,” or DSL-friendly layouts.
  • Overly opinionated rules (e.g., extreme lints, banning constructs) and style wars (e.g., semicolons in JS, Rubocop rules).
  • Cultural trend toward tool-enforced rules over core engineering judgment; “McDonald’s processes” vs “knowing how to cook.”

Language flexibility, idioms, and large projects

• Highly flexible languages (Scala, Perl, Lisp) are said to encourage divergent idioms, making large codebases feel like multiple dialects.
• More opinionated languages with built-in formatters and lints (Go, Rust, Elixir, Dart) are cited as examples where community convergence reduces this “Montreal effect.”
• There is disagreement over whether a global “style czar” per language is desirable; many prefer per-codebase or per-community conventions.

Tooling, representation, and alternatives

• Several ecosystems already use style and architecture tools (PHP’s phpcs/phpstan/phpat, Rust’s clippy, Elixir/Dart formatters) with generally positive reports.
• Some propose moving beyond raw text to AST-based storage so each developer can render code in their preferred style, though practical issues (errors, verbosity, tooling) are noted.
• Others emphasize that real long-term risk is architectural inconsistency (e.g., concurrency models, abstractions), not superficial formatting.

Montreal analogy

• Many readers find the “Montreal problem/effect” metaphor weak or misleading, since architectural and cultural diversity is a strength of the actual city.
• The analogy is seen as low-value or confusing, though some accept it as a colorful way to describe multi-era, multi-style codebases.