O problema de Montreal: por que linguagens de programação precisam de um czar de estilo
Papel e valor da consistência de estilo
- Muitos argumentam que a consistência básica (indentação, posicionamento de chaves, evitar diffs enormes apenas de estilo) claramente ajuda na legibilidade e na manutenção, especialmente em equipes grandes.
- Outros dizem que o estilo tem pouco impacto em comparação com design, nomenclatura e arquitetura; é possível escrever código ilegível e, ainda assim, perfeitamente “estilizado”, e bons engenheiros deveriam conseguir ler qualquer estilo razoável.
- Alguns observam que um estilo inconsistente força esforço cognitivo extra (“isso é diferente por um motivo ou é só estilo?”) e que violações de estilo costumam ocorrer junto com bugs.
Argumentos a favor de formatação automática e guias de estilo
- Os defensores veem autoformatadores (gofmt, rustfmt, Black, etc.) como uma forma de:
- Eliminar bikeshedding e picuinhas em PRs.
- Tornar bases de código visualmente uniformes e mais rápidas de escanear.
- Permitir que humanos concentrem as revisões na lógica, não em espaços em branco.
- Formatadores fornecidos pela linguagem, não configuráveis ou apenas pouco configuráveis, são elogiados por encerrar debates improdutivos.
- Linters e orientações “idiomáticas” são vistos como especialmente valiosos em bases de código grandes e de longa duração.
Argumentos contra padrões rígidos e “czars de estilo”
- Alguns detestam fortemente guias de estilo e ferramentas rígidas, vendo-os como imposições arbitrárias que não garantem legibilidade e podem até prejudicá-la.
- As reclamações incluem:
- Formatadores destruindo alinhamentos deliberados, “tabelas” ou layouts amigáveis a DSLs.
- Regras excessivamente opinativas (por exemplo, lints extremos, proibição de construções) e guerras de estilo (por exemplo, ponto e vírgula em JS, regras do Rubocop).
- Uma tendência cultural de regras impostas por ferramentas em vez de julgamento de engenharia central; “processos do McDonald’s” versus “saber cozinhar”.
Flexibilidade da linguagem, idioms e projetos grandes
- Diz-se que linguagens altamente flexíveis (Scala, Perl, Lisp) encorajam idioms divergentes, fazendo bases de código grandes parecerem vários dialetos.
- Linguagens mais opinativas, com formatadores e lints embutidos (Go, Rust, Elixir, Dart), são citadas como exemplos em que a convergência da comunidade reduz esse “efeito Montreal”.
- Há discordância sobre se um “czar de estilo” global por linguagem é desejável; muitos preferem convenções por base de código ou por comunidade.
Ferramentas, representação e alternativas
- Vários ecossistemas já usam ferramentas de estilo e arquitetura (phpcs/phpstan/phpat do PHP, clippy do Rust, formatadores do Elixir/Dart) com relatos geralmente positivos.
- Alguns propõem ir além do texto bruto para armazenamento baseado em AST, de modo que cada desenvolvedor possa renderizar o código no estilo que preferir, embora sejam apontados problemas práticos (erros, verbosidade, ferramentas).
- Outros enfatizam que o verdadeiro risco de longo prazo é a inconsistência arquitetural (por exemplo, modelos de concorrência, abstrações), e não a formatação superficial.
Analogia com Montreal
- Muitos leitores acham a metáfora do “problema/efeito Montreal” fraca ou enganosa, já que a diversidade arquitetônica e cultural é uma força da cidade real.
- A analogia é vista como de pouco valor ou confusa, embora alguns a aceitem como uma forma colorida de descrever bases de código com várias épocas e estilos.