蒙特利尔问题：为什么编程语言需要一位风格沙皇

风格一致性的作用与价值

• 许多人认为，基础一致性（缩进、大括号位置、避免巨大的纯风格差异）显然有助于可读性和维护性，尤其是在大型团队中。
• 另一些人则认为，与设计、命名和架构相比，风格的影响很小；你可以写出难以阅读但完全“符合风格”的代码，而优秀的工程师应该能够读懂任何合理的风格。
• 还有人指出，不一致的风格会迫使人付出额外的认知成本（“这处不同是有原因，还是只是风格问题？”），而且风格违规往往与 bug 同时出现。

支持自动格式化和风格指南的论点

• 支持者认为，自动格式化工具（gofmt、rustfmt、Black 等）是一种可以：
  • 消除无谓争论和 PR 里的吹毛求疵。
  • 让代码库在视觉上更统一，也更容易快速浏览。
  • 让人类在评审时把注意力放在逻辑上，而不是空白字符上。
• 语言自带的、不可配置或仅能有限配置的格式化器，被赞赏为终结无效争论的一种方式。
• 规范检查器和“惯用”指南被视为在大型、长期存在的代码库中特别有价值。

反对僵化标准和“风格沙皇”的论点

• 有些人非常不喜欢风格指南和僵化工具，认为它们是任意施加的约束，既不能保证可读性，甚至还可能损害可读性。
• 常见抱怨包括：
  • 格式化工具破坏了刻意的对齐、“表格”布局或适合 DSL 的排版。
  • 过度武断的规则（例如极端 lint、禁止某些结构）以及风格战争（例如 JS 中是否使用分号、Rubocop 规则）。
  • 文化上越来越倾向于由工具强制规则，而不是依赖核心工程判断；“麦当劳式流程”对比“知道怎么做饭”。

语言灵活性、惯用法与大型项目

• 高度灵活的语言（Scala、Perl、Lisp）被认为会鼓励分化的惯用法，使大型代码库看起来像多种方言并存。
• 更有主见、内置格式化器和 lint 的语言（Go、Rust、Elixir、Dart）被举为例子，说明社区趋同如何减少这种“蒙特利尔效应”。
• 对于每门语言是否都应有一个全局“风格沙皇”，存在分歧；许多人更偏好按代码库或社区来制定规范。

工具、表示方式与替代方案

• 一些生态系统已经在使用风格和架构工具（PHP 的 phpcs/phpstan/phpat、Rust 的 clippy、Elixir/Dart 的格式化器），并普遍反馈积极。
• 也有人提议超越原始文本，改为基于 AST 的存储，这样每个开发者都能按自己偏好的风格渲染代码，不过也提到了实际问题（错误、冗长、工具链）。
• 另一些人强调，真正的长期风险在于架构不一致（例如并发模型、抽象），而不是表面的格式问题。

蒙特利尔类比

• 许多读者认为“蒙特利尔问题/效应”这一隐喻很弱或有误导性，因为现实中的这座城市的建筑与文化多样性本身就是一种优势。
• 这个类比被看作价值不高或令人困惑，不过也有人接受它，把它当作一种生动的方式来描述跨时代、跨风格的代码库。