El problema de Montreal: por qué los lenguajes de programación necesitan un zar del estilo

Rol y valor de la consistencia de estilo

• Muchos sostienen que una consistencia básica (sangría, ubicación de llaves, evitar diffs enormes solo de estilo) claramente ayuda a la legibilidad y al mantenimiento, especialmente en equipos grandes.
• Otros dicen que el estilo tiene poco impacto comparado con el diseño, los nombres y la arquitectura; puedes escribir código ilegible y aun así perfectamente “estilizado”, y los buenos ingenieros deberían leer cualquier estilo razonable.
• Algunos señalan que un estilo inconsistente obliga a un esfuerzo cognitivo adicional (“¿esto es distinto por una razón o solo por estilo?”) y que las violaciones de estilo suelen coincidir con bugs.

Argumentos a favor del formateo automático y las guías de estilo

• Quienes lo apoyan ven los autoformateadores (gofmt, rustfmt, Black, etc.) como una forma de:
  • Eliminar la discusión estéril y los detalles menores en las PR.
  • Hacer que las bases de código sean visualmente uniformes y más rápidas de escanear.
  • Permitir que los humanos enfoquen las revisiones en la lógica, no en los espacios en blanco.
• Se elogia a los formateadores provistos por el lenguaje, no configurables o solo estrechamente configurables, por poner fin a debates improductivos.
• Los linters y la orientación “idiomática” se consideran especialmente valiosos en bases de código grandes y de larga vida.

Argumentos en contra de estándares rígidos y de los “zares del estilo”

• A algunos les disgustan mucho las guías de estilo y las herramientas rígidas, viéndolas como imposiciones arbitrarias que no garantizan legibilidad e incluso pueden perjudicarla.
• Las quejas incluyen:
  • Formateadores que destruyen la alineación deliberada, las “tablas” o disposiciones favorables a DSL.
  • Reglas excesivamente opinadas (por ejemplo, lints extremos, prohibir construcciones) y guerras de estilo (por ejemplo, puntos y coma en JS, reglas de Rubocop).
  • Una tendencia cultural hacia reglas impuestas por herramientas en lugar del juicio de ingeniería central; “procesos tipo McDonald’s” frente a “saber cocinar”.

Flexibilidad del lenguaje, modismos y proyectos grandes

• Se dice que los lenguajes muy flexibles (Scala, Perl, Lisp) fomentan modismos divergentes, haciendo que las bases de código grandes se sientan como múltiples dialectos.
• Los lenguajes más opinados, con formateadores y lints integrados (Go, Rust, Elixir, Dart), se citan como ejemplos en los que la convergencia de la comunidad reduce este “efecto Montreal”.
• Hay desacuerdo sobre si un “zar del estilo” global por lenguaje es deseable; muchos prefieren convenciones por base de código o por comunidad.

Herramientas, representación y alternativas

• Varios ecosistemas ya usan herramientas de estilo y arquitectura (phpcs/phpstan/phpat de PHP, clippy de Rust, formateadores de Elixir/Dart) con informes generalmente positivos.
• Algunos proponen ir más allá del texto bruto hacia almacenamiento basado en AST, de modo que cada desarrollador pueda renderizar el código en su estilo preferido, aunque se señalan problemas prácticos (errores, verbosidad, herramientas).
• Otros enfatizan que el verdadero riesgo a largo plazo es la inconsistencia arquitectónica (por ejemplo, modelos de concurrencia, abstracciones), no el formateo superficial.

Analogía de Montreal

• Muchos lectores consideran que la metáfora del “problema/efecto Montreal” es débil o engañosa, ya que la diversidad arquitectónica y cultural es una fortaleza de la ciudad real.
• La analogía se ve como de poco valor o confusa, aunque algunos la aceptan como una forma colorida de describir bases de código de múltiples épocas y estilos.