¿Sería una mala idea ejecutar periódicamente formateadores de código en un repositorio?

Estoy pensando en crear un trabajo cron que verifique el código, ejecute formateadores de código y, si algo cambia, confirma los cambios y los empuja hacia atrás.

La mayoría de los proyectos que usan autoformadores los colocan en un git hook, pero hacerlo automáticamente cada pocas horas eliminaría la carga de cada desarrollador para instalar el git hook.

Todavía animaría a todos a escribir código limpio y bien formateado, y tal vez pueda hacer que el sistema haga ping automáticamente a los desarrolladores cuando el código que escribieron se vuelva a formatear, para que sepan qué hacer en el futuro.

Suena bien, pero preferiría tener personas responsables de cometer cambios de código, no bots.

Además, desea asegurarse absolutamente de que esos cambios no rompan nada. Por ejemplo, tenemos una regla que ordena las propiedades y métodos alfabéticamente. Esto puede tener un impacto en la funcionalidad , por ejemplo, con el orden de datos y métodos en archivos WSDL de contratos WCF.

En cambio, trataría de facilitar que todos los miembros del equipo apliquen el formato de código automático de acuerdo con el estándar de su equipo directamente dentro de su editor o IDE , al archivo de código fuente actual (o partes seleccionadas de él). Esto le da a los miembros de su equipo más control sobre cómo y cuándo se lleva a cabo el formateo, les permite inspeccionar el código antes de que se confirme en el formulario final y probarlo después de que se realizó el formateo , no antes.

Si todos o la mayoría de los miembros de su equipo usan el mismo editor, esto no debería ser demasiado difícil. Si todos usan una diferente, entonces su enfoque podría ser la segunda mejor solución, siempre y cuando el equipo lo respalde. Sin embargo, le recomiendo que instale medidas de seguridad adicionales, como compilaciones nocturnas y pruebas automatizadas que se ejecutan después de cada modificación automática de código.

Es una mala idea, no solo porque desalienta a las personas a escribir código decente, sino también porque el formateo se mostrará a medida que el código cambie en su VCS (espero que use uno), enmascarando el flujo histórico del desarrollo del código. Peor aún, cada acción de formateo de código (de hecho, cada cambio en el código) tiene la posibilidad de introducir errores, ya sea manual o automatizado. Por lo tanto, su formateador ahora puede introducir errores en su código que no pasarán por revisiones de código, pruebas unitarias, pruebas de integración, etc. hasta posiblemente meses después.

Tendería a creer que es una buena idea (ejecutar automáticamente formateadores de código), pero esa es solo mi opinión.

No los ejecutaré periódicamente, pero si es posible antes de que se confirme el control de versiones.

Con git , un gancho previo a la confirmación que sería útil. En muchos proyectos C o C ++ creados con algunos Makefile , estoy agregando algunos indentobjetivos (que ejecutan formateadores de código adecuados como indento astyle) y espero que los contribuyentes se ejecuten make indentregularmente. Por cierto, incluso puede agregar algunas makereglas para asegurarse de que los ganchos git se hayan instalado (o para instalarlos).

Pero realmente, es más un problema social que técnico . Desea que su equipo confirme código limpio y bien formateado, y esa es una regla social de su proyecto. (No siempre hay una respuesta técnica para cada problema social).

El control de versiones es principalmente una herramienta para ayudar a la comunicación entre desarrolladores humanos (incluido usted mismo dentro de unos meses). Su software no necesita VC o formato, pero su equipo sí.

Por cierto, diferentes comunidades y diferentes lenguajes de programación tienen diferentes puntos de vista sobre el formato de código. Por ejemplo, Go solo tiene un estilo de formato de código, pero C o C ++ tienen muchos de ellos.

Creo que es una mala idea. Muchas de las respuestas ya cubren que ensucia la historia al dificultar determinar quién realmente agregó una línea y que alienta a las personas a cometer lo que sea y el robot de formato lo manejará.

Un mejor enfoque sería incorporar un verificador de formato en su herramienta de compilación. (En Java hay Checkstyle ). Entonces, solo permita que las personas fusionen sus ramas con la rama principal si la compilación pasa (incluido el formato).

Si permite que las personas se comprometan directamente con la rama principal (como en Subversion, por ejemplo), entonces todavía tendrá que asegurarse de que todos tengan la disciplina para confirmar solo el código formateado (o que el servidor solo acepte las confirmaciones una vez que se hayan ejecutado algunas comprobaciones )

En general, creo que es una mala idea. En principio es una idea válida, pero en realidad puede ser problemática. Hacer que el formateador de código rompa su código es una posibilidad real, y solo se necesita una ejecución de formateo para que sus desarrolladores respondan con hostilidad (probablemente justificada) (por ejemplo, "¡Su pésimo formateador de código rompió la compilación, apáguelo ahora! " ).

En la misma línea que la recomendación de @ BasileStarynkevitch, utilizamos ganchos posteriores a la recepción del servidor git para enviar "correos electrónicos de asesoramiento" sobre el estilo del código.

Si presiono un commit que contiene violaciones de estilo, el servidor de origen de git me enviará un correo electrónico que me informa que violé las pautas de estilo y recomienda que arregle mi código. Sin embargo, no impone esto porque puede haber razones válidas para romper el estilo de la casa (cadenas largas que exceden el límite de longitud de línea, por ejemplo).

Si se trata de un problema sistémico que está dañando la base de código, podría ser hora de comenzar a plantear problemas de estilo de código en las revisiones de código. Un estilo de código deficiente puede enmascarar errores y hacer que el código sea más difícil de leer, por lo que puede ser un problema de revisión de código válido.

Para agregar al aspecto del "problema social" de las cosas, puede valer la pena alentar a las personas a reparar defectos cosméticos y estilísticos a medida que los encuentran. Tenemos un mensaje de confirmación estándar "Cosmético". para las correcciones de estilo de código que otros desarrolladores saben que no contienen cambios importantes.

Como dice @DocBrown, otra opción es aplicar el estilo de código dentro de su IDE. Usamos CodeMaid con Visual Studio para corregir muchos errores de estilo comunes. Se ejecutará al guardar los archivos de código, lo que significa que el código de estilo incorrecto nunca debería llegar al repositorio ... en teoría :-).

Sí, creo que es una mala idea. No me malinterpreten, la razón para hacerlo suena genial, pero el resultado aún podría ser horrible.

Tendrá conflictos de fusión al extraer una rama rastreada, al menos me temo que ese sería el caso, aunque podría estar equivocado.

No quiero probarlo ahora mismo en el trabajo, pero deberías probarlo tú mismo.

De hecho, puede consultar una confirmación reciente. Crea una nueva sucursal, comete algo insignificante, elige o fusiona sin compromiso automático.

Luego ejecute su secuencia de comandos, tire y si su resultado es un desastre de fusión horrible, entonces definitivamente no debe hacer esto, a la luz del día.

En su lugar, podría ponerlo en una versión nocturna o semanal.

Pero incluso una noche podría ser una mala idea.

Puede ejecutarlo semanalmente, cuando esté seguro de que no surgirán conflictos de fusión porque todo está terminado el lunes.

De lo contrario, ejecútelo 1-2 veces al año en temporada de vacaciones, cuando no se produzcan conflictos de fusión.

Pero la solución puede depender de su prioridad para el estilo de código.

Creo que sería mejor crear un script de configuración que cree automáticamente el repositorio git y establezca los ganchos para el proyecto.

O puede incluir el script de configuración de enlace en una carpeta para sus desarrolladores dentro del proyecto y simplemente verificarlo en git.

Algo que no he visto mencionado es el hecho de que a veces hay razones legítimas para no formatear algo de acuerdo con un conjunto de reglas. A veces, la claridad del código mejora al ir en contra de una directriz dada que el 99% del tiempo tiene sentido. Los humanos necesitan hacer esa llamada. En esos casos, el formateo automático del código terminaría haciendo las cosas menos legibles.

Es una idea horrible.

Si uno de mis colegas desarrolladores realizara cambios gratuitos en los archivos fuente, no pasaría una revisión de código. Simplemente hace la vida más difícil para todos. Cambia el código que necesita cambiar, nada más. Los cambios sin sentido conducen a conflictos de fusión, lo que puede conducir a errores, y solo crean un trabajo sin sentido.

Si quieres hacer esto regularmente, es horrible.

Y luego está la cuestión de qué tipo de cambios realiza el formateador de código. Utilizo el formateo automático en mi editor, funciona razonablemente bien y puedo mejorar las cosas cuando el formateo automático no es perfecto. Si usa un formateador de código que va más allá de eso, no va a mejorar el código, lo va a empeorar.

Y luego está el problema social. Hay personas que quieren obligar a todos a usar su estilo de código, y hay personas más flexibles. Algo así podría ser sugerido por el tipo de desarrollador "gramer-nazi" (intencionalmente ortográfico) que quiere imponer su estilo a todos los demás. Espere una reacción violenta y espere que los desarrolladores flexibles, normalmente fáciles de poner, pongan su pie abajo.

No menciona el VCS que usa, pero dependiendo de eso, otra opción es tener un enlace del lado del servidor. Un VCS como git lo admite. Puede instalar un enlace del lado del servidor que ejecuta el formateador en la versión que se está presionando y luego compara el archivo formateado con la versión que se está empujando. Si difieren, el desarrollador no utilizó el formato correcto y el servidor podría rechazar el envío. Esto obligaría a sus desarrolladores a solo insertar código con el formato deseado, lo que les animaría a escribir código limpio desde el principio, haría que los desarrolladores sean responsables de haber probado el código formateado correctamente y evitaría que sus desarrolladores tengan que instalar manualmente un lado del cliente gancho.

Es una compensación entre un formato de código más limpio y un historial de git más exacto y más fácil de entender. Depende de la naturaleza de su proyecto y con qué frecuencia se sumerge en la historia de git o la culpa para comprender lo que está sucediendo. Si está trabajando en algo nuevo y no tiene que mantener la compatibilidad con versiones anteriores, el historial generalmente no juega un papel importante.

Esta idea es similar a algunas otras respuestas, pero no puedo comentar mis sugerencias.

Una opción es establecer un alias (o gancho, o lo que sea) para la función de confirmación, que ejecuta el formateador de código en el código a confirmar antes de que se confirme.

Podría tener 2 (o más) resultados:

1) Muestre al usuario los cambios propuestos y solicite su aprobación para aplicar y confirmar los cambios.

2) Ignore los cambios propuestos y confirme el código original.

También podría agregar más flexibilidad a estas opciones, como la posibilidad de editar los cambios propuestos en la opción 1. Otra idea (dependiendo de cuán duro desee impulsar estos estándares de codificación) es que el sistema le envíe un informe de algún tipo cuando La opción 2 está seleccionada.

Esto puede ser un buen equilibrio de autocomprobación de todo el código que desee, al tiempo que permite flexibilidad a los desarrolladores para satisfacer sus necesidades. También permite la opción de no 'rechazar automáticamente' el código con diferencias de formato como se menciona en otras respuestas. Con 'Revisé y aprobé las correcciones de formato automático; opción "commit", aún mantiene la responsabilidad personal por el trabajo de cada desarrollador y no se mete con VCS.

No lo haré en el repositorio, pero lo haré en guardar si la herramienta lo admite. Eclipse es uno y además haría la limpieza del código, incluida la clasificación.

Lo bueno es que es parte del proyecto, por lo que cada desarrollador lo obtendrá para su proyecto.

Como un bono adicional, las fusiones se simplificarían significativamente, ya que las cosas no se saltan.

Las revisiones de código evitarán cualquier error.

Otro lugar donde lo haría es incluirlo en la construcción. En mi caso, lo tengo de tal manera que las compilaciones de Maven reformatearán el XML y limpiarán los archivos pom y reformatearán el código.

De esa forma, cuando los desarrolladores estén listos para impulsar, todo se limpiará para su solicitud de extracción.