¿Es una buena idea imponer el mismo formato de código para todos los desarrolladores?

Actualmente trabajo en un lugar donde se aplica un formato de código estándar y el código se formatea automáticamente al guardar el archivo, tal como está a punto de hacerlo. Como nuevo miembro de la compañía, encontré que las reglas comunes de formato me dieron una sensación cálida y confusa de que "estos chicos saben lo que están haciendo", por lo que no podría estar más feliz. ;) Como nota relacionada, con las reglas de formato comunes también aplicamos ciertas configuraciones de advertencia del compilador bastante estrictas en Eclipse, con la mayoría de ellas configuradas en Error, muchas configuradas en Advertencia y casi ninguna configurada en Ignorar.

Yo diría que hay dos razones principales para imponer un formato de código único en un proyecto. Primero tiene que ver con el control de versiones: con todo el mundo formateando el código de manera idéntica, se garantiza que todos los cambios en los archivos serán significativos. No se limite a agregar o quitar un espacio aquí o allá, y mucho menos reformatear un archivo completo como un "efecto secundario" de cambiar realmente solo una línea o dos.

La segunda razón es que hace que los egos de los programadores salgan de la ecuación. Con todo el mundo formateando su código de la misma manera, ya no se puede decir tan fácilmente quién ha escrito qué. El código se convierte en una propiedad más anónima y común, por lo que nadie debe sentirse incómodo por cambiar el código de "alguien más".

Esas son las razones principales, hay otras también. Me resulta reconfortante no tener que preocuparme por pensar en el formato del código, ya que Eclipse lo hará automáticamente cuando guarde. Es sin preocupaciones, como escribir documentos con LaTeX: se formatea después y no tiene que preocuparse por eso mientras escribe. También he trabajado en proyectos donde todos han tenido sus propios estilos. Luego tienes que pensar en temas estúpidos y sin sentido, como si está bien modificar el código de otra persona en tu propio estilo, o si deberías intentar imitar su estilo.

El único argumento en contra de la configuración de formato de código común que se me ocurre para su caso es que aparentemente es un proyecto en curso, por lo que causará muchos cambios innecesarios en todos los archivos, desordenando los historiales de archivos reales. El mejor escenario es si puede comenzar a aplicar la configuración desde el principio de un proyecto.

Todo desarrollador de software profesional preferirá adoptar un (buen) estándar en lugar de meterse en guerras evangélicas en vez de estilo, por las mismas razones que ha descrito.

Muchos desarrolladores de software libran guerras evangélicas ......

Dependiendo de tu posición dentro del equipo y la dinámica del equipo, puedes decidir que ganar la guerra no es posible. En este caso, puede ser mejor no comenzar ...

Sí, es bueno tener estilos de formato de código para todos los desarrolladores.

Diseñe los formatos de estilo de código e impórtelos a todos los desarrolladores.

Esto nos ayudará cuando estemos en un código merging para el sistema de 'Control de versiones'.

¿Qué está tratando de obtener, qué tan reticente anal será en su cumplimiento (y en el nivel de detalle en que se establecerán sus "reglas"), va a intentar imponerlo en el código escrito en diferentes idiomas, ¿va a intentar aplicarla retroactivamente en el código existente?

1. un aspecto y comportamiento comunes al código puede ayudar a hacer que el código sea más legible, pero también puede empeorar las cosas si se ve y se siente mal. La notación _hungarian_lpfstr es un buen ejemplo :)
2. He visto "estándares de código" que imponen la cantidad de espacios en blanco entre los bloques de comentarios, el orden alfabético de los nombres de los métodos y otras tonterías. No hagas eso.
3. Los diferentes idiomas tienen diferentes estándares a los que están acostumbradas las personas que tienen experiencia en su uso. Algunos incluso imponen estos estándares (piense que Python, Cobol, Visual Studio impone automáticamente las convenciones de refuerzo del estilo C ++, mientras que Java utiliza el estilo C por convención, etc.).
4. nunca cambie el código existente por cambiarlo, solo está introduciendo nuevos problemas de esa manera. Y eso significa que las secciones de código, así como todos los archivos de origen. Por lo tanto, no intente reformatear el código existente cuando alguien cambia una sola línea en un archivo de 1000 líneas.
5. los programadores experimentados pueden ser mucho más productivos si no tienen que pensar la mitad del tiempo si lo que escriben "se verá bien" en el sistema de aprobación automático o en el revisor. También tendrán la costumbre de escribir código limpio simplemente porque eso es lo que funciona, incluso si hay pequeñas diferencias entre sus estilos naturales.

Entonces, si bien hay buenas razones para imponer un estilo y un estándar específicos, hay buenas razones para no hacerlo (también) estrictamente.

Sí, la coherencia es una buena idea, por razones otros tienen mencionado .

Solo quería agregar un par de puntos que no se han utilizado en ningún otro lugar:

• Oracle ha publicado un conjunto de convenciones para Java, que son el estándar de facto.
  • El uso de estos debería ayudarte a evitar argumentos sobre qué estilo seguir.
  • Muchas bibliotecas públicas y proyectos de código abierto tienden a usar estas convenciones, por lo que cuando necesite verlas, el formato debería ser familiar.
  • El formateador de Eclipse tiene reglas integradas que coinciden con estas convenciones, lo que también debería ayudar.
• Es posible que desee considerar la creación de un enlace en la configuración de control de origen para que el código se formatee automáticamente antes de que llegue a la rama principal.
  • Puedes evitar batallas con programadores especialmente obstinados que se niegan a seguir el estándar. Incluso pueden usar su propio formato mientras trabajan, ¡lo cual se estandarizará más adelante!
  • Si terminas usando configuraciones de formato personalizadas (por ejemplo, muchas personas ignoran la convención de "máximo 80 caracteres por línea") solo tienes que realizar cambios en un lugar.

Estaba en un equipo que usaba el plugin Checkstyle . En lugar de utilizar las funciones listas para usar, formamos un pequeño comité de desarrolladores interesados. Discutimos sobre lo que parecía faltar, lo que parecía excesivo y resolvimos las cosas. Todos aprendimos algo en el proceso y fortalecimos los músculos de los desarrolladores.

(Ejemplos de nuestras decisiones: 72 caracteres de ancho es demasiado pequeño, pero 120 fue mejor; es mejor usar _ALLCAPS para finales estáticas; es una buena idea imponer la salida única desde una función).

Cuando tuvimos revisiones de código, una de las primeras preguntas fue: "¿Lo has revisado con Checkstyle?" El cumplimiento de los estándares de codificación fue en gran parte automatizado, y distrajo la atención de que el revisor era delicado. Fue maravillosamente fácil hacer que Checkstyle destaque una firma de método, haga clic con el botón derecho y cambie una variable a final. También podría corregir las muescas y llaves para que el código de todos tenga una apariencia similar. ¿Falta un Javadoc para una función pública? Checkstyle marcará la función.

(Eliminar el olor del código es más importante que un formato consistente. Esto es un beneficio de las herramientas automatizadas.)

Colocaría las herramientas automatizadas como Checkstyle menos como imponiendo el mismo formato y más en alentar una apariencia similar. Y cuando estás criando gatos, una herramienta automatizada puede ayudar a mejorar las habilidades y reducir el olor del código sin dañar los egos frágiles.

Si vas a mantener el mismo IDE e incorporas algunas herramientas de formateo, es una buena idea porque no estás requiriendo demasiado esfuerzo. Mantenga las reglas simples con un enfoque en la legibilidad y no en retentividad anal . Esa debería ser la vara de medir.

Aunque una bola de barro con un formato consistente es mejor que solo una bola de barro, sería mejor gastar su tiempo en limpiarla en lugar de ser demasiado exigente con respecto a dónde van los soportes. No se convierta en el administrador con cabeza de alfiler que siente que está haciendo su trabajo contando los espacios de sangría durante una revisión del código y asegurándose de que las nuevas hojas de portada están en los Informes TPS .

Las preferencias personales son solo eso y rara vez mejoran la producción: enlace

Si lo hace, supéralo y haz algo.

Recomiendo encarecidamente que los humanos apliquen el formato del código, y que las infracciones menores se pasen por alto o se traten con delicadeza. Las razones para esto son, brevemente,

1. La máquina se equivoca en el peor momento posible, y generalmente cuando está utilizando una nueva función de idioma. ¿Cómo manejará los cierres en Java, etc.? Jalopy tiene problemas con las enumeraciones con funciones de miembro.
2. Creo que es una carga muy razonable ponerle al programador que produzca un código para la compañía que se parece al código de la compañía. Me ha resultado útil mencionar que así es como se formatea el código "aquí", no cómo se debe formatear todo el código en todas partes. Su compañía anterior puede haber elegido un camino diferente, y eso está bien. No a diferencia del lenguaje vernáculo, hay expresiones específicas de la cultura de su código que desea resaltar.
3. La aplicación de la sintaxis de código se realiza mejor con las revisiones de código:
   1. Si el formato es importante, lo que hace que su organización haga revisiones de código. Esto es de gran beneficio.
   2. Si se rompe una regla de formato, un humano puede verla y juzgar mejor que una máquina si la intención se transmite de manera más limpia. Esto es muy raro, pero sucede ocasionalmente.

Con respecto a "legibilidad = > productividad", la estructura del código (como las clases y funciones de responsabilidad única) le comprará mucho más rápido que el formato del código. El formato de código puede ser una ayuda, pero diferentes mentes analizan las declaraciones de manera diferente, no todos serán "más productivos". Me gustaría duplicar la estructura de código sobre el formato porque eso es algo que también lo empujará a hacer revisiones de código y hará que el equipo piense cómo funciona el programa, no cómo se ve un solo bucle.

No soy un gran fanático del Diseño Dirigido por Dominio, pero es un modelo reciente que tiene una idea MUY definida en cuanto a cómo se debe estructurar el código y las convenciones de formato del código que se derivan naturalmente de un programa estructurado de Diseño Dirigido por Dominio. Nuevamente ... no me gusta la DDD, pero es un gran ejemplo porque está muy bien definido.

Supongo que el tema de esta respuesta es, Hacer revisiones de código y dejar que el formato fluya desde la cultura y fuera del proceso de revisión.

En general, suponiendo que contrates desarrolladores razonables, es una mala idea imponer un formato de código universal. Sin embargo, es una buena idea adoptar el código directrices .

Nunca he visto un conjunto de reglas de formato de código que optimice la legibilidad en todos los casos. Del mismo modo, no hay reglas gramaticales aplicables al 100% en inglés: nuestros cerebros simplemente no están conectados de esa manera. Por lo tanto, utilice las directrices, pero dé a los desarrolladores la libertad de anularlas cuando lo consideren oportuno.

Dicho esto, una buena regla de "seguir la convención de código que ya existe en el archivo / proyecto" es buena.

Pero tenga en cuenta que el formato contribuye mucho menos a la legibilidad que la forma en que el código está organizado de manera lógica. ¡He visto muchos códigos de espagueti ilegibles con formato perfecto!

No creo que haya una respuesta simple a esto. No es una pregunta de sí o no. Si bien creo que las convenciones de estilo y denominación son importantes hasta cierto punto, también es bastante fácil perder demasiado tiempo pensando en ello. Es mejor responder con el ejemplo.

En un proyecto en particular en el que estaba, no había ninguna convención. Cada desarrollador hizo las cosas a su manera. Debido a la relativa inexperiencia de este equipo, pasar de una clase a otra fue realmente discordante. El estilo era menos problemático que el problema de las convenciones de nombres. Un desarrollador haría referencia a los elementos de la interfaz de usuario con una terrible notación húngara (una práctica tonta en la era de los IDE modernos), uno nombraría a los miembros privados de una manera, otro los nombraría de forma diferente. Nunca supiste lo que estabas viendo.

En el extremo opuesto, un equipo utilizó StyleCop (este fue un proyecto .Net) como parte de su proceso de construcción. Lo que es peor, es que también usaron la mayoría de las reglas predeterminadas. Así que harías algo totalmente normal en términos de espaciado de líneas o colocación de corchetes, y la construcción se echaría a perder por ello. Se desperdició mucho tiempo simplemente agregando espacios y líneas a las cosas, y todos, incluidos los tíos que insistieron en usar StyleCop, terminaron haciéndolo casi en cada compromiso. Fue una enorme pérdida de tiempo y dinero.

Entonces, lo que estoy señalando aquí es que ser inflexible no es la respuesta, pero estar en el Salvaje Oeste tampoco lo es. La respuesta real es encontrar el lugar que tenga más sentido, que en mi opinión es no tener herramientas automáticas que verifiquen las cosas, pero tampoco lanzar la convención al viento.

Mi principal argumento en contra del estilo de codificación común es que un programador experimentado se utiliza para leer su propio estilo. Puedes entrenar la mano para escribir un estilo específico, pero es casi imposible entrenar el ojo para entender un estilo que odias. Un programador escribe un fragmento de código una vez y luego lo lee una y otra vez durante el desarrollo y la depuración. Si cada vez que lee su propio código se esfuerza por entenderlo, ya que se vio obligado a escribirlo en un estilo MALO, será muy infeliz y menos productivo. Esto es de mi experiencia en.

No estoy muy familiarizado con Eclipse, pero el formato automático de guardado suena como una idea horrible. Un desarrollador debe tener control completo sobre su código, independientemente de si el estilo de codificación se impone o no. La operación de 'guardar' no debe cambiar un solo carácter sin el consentimiento explícito del usuario.

Si su empresa vende código fuente, el estilo de codificación es más importante, pero si vende código compilado es mucho menos relevante.

Esperar que el estilo de codificación haga que el codificador original sea menos distinguible y evite las guerras del ego es una tontería en el mejor de los casos y simplemente estúpido en el peor de los casos. Los grandes programadores siempre producirán un código elegante independientemente del estilo.

También soy muy profesional al otorgar a cada desarrollador la propiedad de unidades de código específicas y en contra de permitir que todos toquen cada pieza de código libremente. Desarrollar unidades completas en el código y ser responsable de ellas le permite al desarrollador sentirse orgulloso de su trabajo y evitar que desarrolle código de mierda, sabiendo que los errores volverán a cazarlo.

Finalmente, cualquier persona que tenga un estilo de codificación profesional siempre asume que su propio estilo de codificación será seleccionado y todos los demás lo seguirán. Imagina que el estilo de codificación que menos te gusta de todos tus co-desarrolladores seleccionados de forma estándar. ¿Sigues a favor de imponer un estilo de codificación?

Los buenos desarrolladores son personas creativas, dales un poco de licencia artística. "Mantenlo simple" debe ser el mantra de los programadores. Tengo dos reglas:

Regla 1: Dar variables / cursores / objetos / procedimientos / cualquier NOMBRE SENSIBLE. Nombres no ambiguos que aportan significado y comprensión a su código.

Regla 2: Use sangría para mostrar la estructura de su código.

Eso es todo.

Para mí, la principal ventaja de un formato común que se aplica automáticamente es que ayuda a nuestro seguimiento de cambios & Revisiones de código. git (y la mayoría de las otras herramientas de control de fuente) pueden mostrar diferentes versiones anteriores de los archivos. Al imponer un estilo común, minimiza las diferencias de preferencias del programador.

Un formato para controlarlos todos ... ¿es realmente óptimo?

Es como conducir el auto de otra persona ...

Seguro que puedes subir y conducir en cualquier automóvil, pero estarás más seguro, más cómodo y menos propenso a chocar si te tomas el tiempo de ajustar el asiento, el volante y los espejos para SU preferencia.

Con el código, el formato afecta su comodidad para leer y comprender el código. Si está demasiado lejos de lo que estás acostumbrado, necesitarás más esfuerzo mental. ¿Es necesario infligir esto a los desarrolladores?

+1 a todos los beneficios mencionados hasta ahora, pero ...

La aplicación automática viene con costos que deben considerarse:

-1 al hecho de que los formateadores de código no entienden la estética del formato de código. ¿Cuántas veces ha tenido un formateador de código para destruir un bloque de comentarios que estaba bien alineado en forma tabular? ¿Cuántas veces alineaste a propósito una expresión compleja de una manera determinada para aumentar la legibilidad, solo para que el formateo automático lo convierta en algo que "sigue las reglas", pero es menos legible?

A veces hay soluciones alternativas a estas cosas, pero los desarrolladores tienen cosas más importantes en las que pensar que en cómo evitar que el formateador automático manipule el código.

Tenga reglas de formato, pero permita cierta libertad para aplicar el sentido común.

Las guías de estilo también permiten un análisis programático más sencillo para varios propósitos analíticos.

Google ha publicado un artículo sobre este tema llamado " Buscando construir deuda: Experiencias en gestión de deuda técnica en Google ".

Es idiomas, no códigos. Los humanos tenemos más de 6000 idiomas, así que los traducimos. Así que si quieres que tus "códigos" se comuniquen, tendrás que hacer tus ajustes. Verá que los usuarios tenemos que cambiar nuestros formatos de datos para que no perdamos nuestros datos.

Yo diría que no lo es. Una estructura / formato de código común entre un equipo es definitivamente algo bueno, pero hacerlo de forma automática no lo es. Esto debe ser hecho por humanos, no por computadora.

Mis mayores problemas con el concepto son

1. Si estoy escribiendo el código en un formato y este se reformatea automáticamente, ¿qué incentivo existe para aprender ese formato?
2. Después de ese punto anterior, si no aprendes el formato, todo el punto de autoformato (para facilitar la lectura y modificación del código) se pierde por completo. Aún debe dedicar tiempo a averiguar el formato, ya que está leyendo el código porque no ha aprendido ese formato
3. Creo que sería una experiencia discordante como un desarrollador escribir una clase un día, cerrarla y regresar al día siguiente para ver que es completamente diferente. Eso significa que no solo los demás tienen que aprender su código, usted tiene que aprender su código.
4. También podría fomentar la codificación perezosa. En lugar de presionar a los desarrolladores para que aprendan el formato, pueden escribir en cualquier formato bajo el sol y se verá automáticamente como todos los demás quieren. Esto se remonta al # 2, donde no aprendes el estilo y aún no puedes leerlo correctamente.

Ahora, me inclino a decir que ejecutar un auto-formato en un proyecto que está envuelto sería una buena idea. Esto iniciaría a todos los desarrolladores con el mismo pie para el proyecto cuando vaya a corregir / agregar funciones más adelante. Sin embargo, durante el desarrollo activo, creo que es una opción muy pobre.

Básicamente: ponga la responsabilidad sobre el empleado para aprender el estilo de la empresa, no obligue a que su código sea algo que no es.