The Montreal problem: Why programming languages need a style czar
Advocates of a “style czar” for programming languages argue that consistent, enforced idioms and built‑in formatters reduce cognitive load, ease code reviews, and prevent large codebases from fragmenting into incompatible dialects. Critics counter that style rules are often arbitrary, can stifle individual productivity and expression, and that good design, naming, and architecture matter far more than brace placement or tabs vs spaces. The exchange also highlights broader tensions between flexibility and standardization in languages like Scala, Python, and Go, and whether convergence on tools and patterns should emerge organically or be imposed from above.
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.