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

68

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.

gran ciego
fuente
105
Hay un error lógico aquí. Este método no alentaría a las personas a escribir código bien formateado; ¡más bien alentaría a las personas a no formatear y confiar en el sistema! Si le preocupa que la base del código sea coherente, está bien. Tu objetivo es entrenar a los codificadores para que escriban limpiamente, es un gran error.
Kilian Foth
52
También es teniendo en cuenta el efecto que esto tendrá en características como la culpa, especialmente si el formateador realiza muchos cambios, si la mayoría de las líneas del archivo están marcadas como modificadas por el formateador, pierde parte del valor.
Neil P
13
He tenido problemas con un autoformatter que no se actualiza correctamente y rompe mi código. Algo para tener en cuenta.
isaacg
22
Si es tan importante para usted, podría fallar la compilación cuando el código no esté formateado correctamente. Eso es un poco duro, pero una revisión por pares adecuada haría más o menos lo mismo.
Erno
18
Esta es una excelente idea si su objetivo es lograr que la gente lo odie. Alcanza muy poco, pero ciertamente causará problemas imprevistos.
TonyK

Respuestas:

130

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.

Marcel
fuente
50
También rompe un poco el VCS. No podrá saber quién escribió una línea fácilmente con la culpa, y si hay un conflicto, su VCS no podrá saber que los cambios de la herramienta son solo por estilo y deben descartarse cada vez.
Pierre.Sassoulas
2
Un tema relacionado tangencialmente es aplicar ciertas "acciones de guardar" en un IDE, como hacer que los campos sean finales si es posible. Es un problema porque (al menos en Java) muchos frameworks los establecen a través de la reflexión (por ejemplo, Spring e Hibernate).
Capitán Man
20
@JeffO git blameno es solo para encontrar de quién es la culpa de un error, es para encontrar el commit cuando se agregó / eliminó algo, lo que puede ser útil por varias razones.
Pokechu22
2
"Tenemos una regla que ordena las propiedades y los métodos alfabéticamente" ¡Vaya, eso suena horrible! Tendría que estar constantemente esperando en todo el archivo
Alexander
1
También para Java, la combinación de un verificador de estilo que busca derivaciones del estilo acordado (quizás incluso convirtiéndolo en una advertencia de compilación), y un IDE configurado para formatear el estilo acordado hace que sea muy fácil de detectar y corregir. Es importante que el código se establezca (por falta de una palabra mejor) cuando realmente cambia la funcionalidad, no cuando un bot lo reformatea.
Thorbjørn Ravn Andersen
72

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.

Doc Brown
fuente
77
"Un formateador a mano donde estás 100% seguro de que no rompe nada" - ¿Cuándo te has encontrado con un código que estabas, honestamente, 100% seguro de que nunca se rompería?
Zibbobz
2
@Zibbobz: cualquiera de las herramientas que estamos utilizando para editar código, compilarlo y vincularlo, y también el VCS, puede tener errores, pero eso no nos impide tratar de desarrollar programas de trabajo ;-) Pero vea mi edición.
Doc Brown
Sí apruebo la edición, aunque solo sea porque una onza adicional de precaución vale la pena una libra de depuración. ;)
Zibbobz
@Zibbobz ¡Muy a menudo! Tenga en cuenta que estar 100% seguro de algo no significa que tenga un 100% de posibilidades de ser cierto.
user253751
@immibis: es posible que haya pasado por alto que el comentario hace referencia a una oración que eliminé de mi respuesta hace unos días.
Doc Brown
37

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.

jwenting
fuente
10
Creo que si está hablando de que un bot revise las cosas dentro y fuera de un repositorio, ¿VCS es un hecho?
StarWeaver
11
@StarWeaver pensarías. Pero he trabajado en lugares donde el "repositorio de código" era un directorio protegido al que solo podía acceder un software que funcionaba con su propia cuenta de usuario, sin ningún control de versión excepto una copia de seguridad semanal del directorio con un nombre de directorio con marca de tiempo.
Jwenting
14
Eso es ... Voy a tener pesadillas ahora>.>
StarWeaver
77
@StarWeaver ¿por qué cree Todavía recuerdo ese medio 14 años más tarde;)
jwenting
28

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.

Basile Starynkevitch
fuente
Correcto, pero eso significa que cada desarrollador necesita instalar el enlace de confirmación.
bigblind
17
Sí, pero esa es una regla social, y necesitas varias de ellas. No puede encontrar una solución técnica para cada problema social. Necesitas convencer a la gente. Además, cada desarrollador necesita instalar algún compilador y el sistema de control de versiones en sí.
Basile Starynkevitch
Bien, ¿estás diciendo que la regla social de tener que instalar un git hook es mejor que un sistema automatizado que lo hace? (Pregunta seria, no como una retórica, el tono es difícil de transmitir en Internet :))
bigblind
15
Sí, estoy diciendo eso.
Basile Starynkevitch
17

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 )

Capitán Hombre
fuente
2
pero asegúrese de que el verificador de estilo sea sensato y no imponga cosas extrañas que vayan en contra de cualquier práctica aceptada (y aceptable) (y sí, lo he visto). También puede hacer que el servidor de compilación tenga un error de compilación automática cuando el comprobador de estilo arroja (nuevos) errores.
Jwenting
2
He visto muchos casos en los que el formateo automático produce código ilegible. Especialmente para muchos parens de cierre (es sensato dejar algunos de ellos en líneas separadas, pero al robot no le importa). Otro ejemplo es la división automática de cadenas largas de Java (son largas porque contienen consultas SQL, pero el robot no tiene idea).
18446744073709551615
@ 18446744073709551615 No estoy sugiriendo el formateo automático, estoy sugiriendo la verificación automática . Tus reglas podrían permitir esas cosas.
Capitán Man
16

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 :-).

Karl Nicoll
fuente
Voté este, porque se dirige directamente a ambos lados (deseo de un mejor código + seguridad para no romper la compilación). Sin embargo, después de que la base del código esté en muy buena forma, consideraría que "mala idea" es una redacción algo sólida para automatizar cambios futuros.
donjuedo
10

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.

Con suerte
fuente
7

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.

Andy Lester
fuente
Totalmente de acuerdo. Por ejemplo, alineando los identificadores de variables a la izquierda, todos los signos iguales en una sola columna y todos los valores a la derecha de los signos iguales. Un formateador depreciaría la legibilidad en este caso al reducir las pestañas / espacios cada uno a un solo espacio. Por supuesto, las reglas del formateador podrían escribirse para evitar esto, pero luego necesita un desarrollador asignado solo para escribir el formateador de código. Parece una mala idea por todas partes. Adopte mejores convenciones internas y aplique durante la revisión del código.
ThisClark
7

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.

gnasher729
fuente
4

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.

sigy
fuente
Esto es lo que hace Go, por ejemplo, excepto usar Mercurial. Empujar algo que no sea invariable go fmtse rechaza automáticamente.
Jörg W Mittag
1

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.

Max Yankov
fuente
1

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.

MadisonCooper
fuente
0

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.

Arquímedes Trajano
fuente