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

Suena bien, pero preferiría que las personas responsables de los cambios de código se comprometan, no los robots.

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

En su lugar, trataría de hacer que sea realmente fácil para todos los miembros del equipo aplicar 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 seleccionado partes de ella). Esto le da a los miembros de su equipo más control sobre cómo y cuándo tiene lugar el formateo, les permite inspeccionar el código antes de que se confirme en la forma final, y lo prueban 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 que el equipo lo apoye. Sin embargo, te recomiendo que tengas medidas de seguridad adicionales instaladas, como compilaciones nocturnas y pruebas automatizadas que se ejecutan después de cada modificación automática del código.

Es una mala idea, no solo porque desalienta a las personas a escribir código decente, sino también porque el cambio de formato se mostrará como cambios de código en su VCS (usted usa uno, espero), 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 de unidades, pruebas de integración, etc. hasta meses después.

Tendrí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 versión.

Con git , un gancho de pre-confirmación , sería útil. En muchos proyectos de C o C ++ construidos con algunos Makefile , estoy agregando algunos indent target (que ejecutan adecuadamente los formateadores de código como indent o astyle ) y espere que los colaboradores ejecuten make indent regularmente. Por cierto, incluso puedes agregar algunas reglas make para asegurarte de que los ganchos de git hayan sido instalados (o para instalarlos).

Pero realmente, es más un problema social que técnico . Desea que su equipo cometa un código limpio y bien formateado, Y esa es una regla social de tu 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í lo necesita.

Por cierto, diferentes comunidades y diferentes lenguajes de programación tienen diferentes vistas en el formato de código. Por ejemplo, Go tiene solo 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 cubrieron que ensucia la historia al hacer que sea difícil determinar quién en realidad agregó una línea y que alienta a las personas a simplemente cometer cualquier cosa y el formateo del formato lo manejará.

Un mejor enfoque sería incorporar un comprobador de formato en su herramienta de compilación. (En Java hay Checkstyle ). Luego, solo se permite que las personas fusionen sus sucursales 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 deberá asegurarse de que todos tengan la disciplina para ingresar solo el código formateado (o que el servidor solo acepte las confirmaciones una vez que se realicen algunas comprobaciones se han ejecutado).

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

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

Si presiona una confirmación que contiene violaciones de estilo, el servidor de origen de git me enviará un correo electrónico que me informa que rompí las pautas de estilo y recomienda que arreglo 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 la línea, por ejemplo).

Si se trata de un problema sistémico que está dañando la base de código, podría ser el momento 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 de "problema social" de las cosas, puede valer la pena alentar a las personas a solucionar los defectos estéticos y estilísticos a medida que los encuentran. Tenemos un mensaje de compromiso estándar "Cosmético". para las correcciones de estilo de código que otros desarrolladores saben no contienen cambios de última hora.

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

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

Tendrás 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, puedes revisar un compromiso reciente. Haga una nueva sucursal, cometa algo pequeño, elija una cereza o fusione sin confirmación automática.

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

En su lugar, podrías ponerlo en una compilación nocturna o semanal.

Pero incluso una noche puede ser una mala idea.

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

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

Pero la solución podría depender de su prioridad para el estilo de código.

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

O puedes incluir el script de configuración de gancho en una carpeta para tus desarrolladores dentro del proyecto y simplemente registrarlo 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 pauta dada que el 99% de las veces tiene sentido. Los humanos necesitan hacer esa llamada. En esos casos, el formato automático de código terminaría haciendo las cosas menos legibles.

Es una idea horrible.

Si uno de mis colegas desarrolladores realizó cambios gratuitos en los archivos de origen, 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 inútiles conducen a conflictos de fusión, que pueden llevar a errores, y simplemente crean trabajo inútil.

Si quieres hacer esto de forma regular, es simplemente horrible.

Y luego está la pregunta de qué tipo de cambios realiza el formateador de códigos. Utilizo el formato automático en mi editor, funciona razonablemente bien y puedo mejorar las cosas cuando el formato 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 "grammer-nazi" (deletreo intencional) que quiere forzar su estilo en todos los demás. Espere una reacción negativa, y espere que los desarrolladores flexibles, que normalmente son fáciles de usar, 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 soporta eso. Podría instalar un gancho del lado del servidor que ejecute el formateador en la versión que se está enviando y luego compare el archivo formateado con la versión que se está enviando. Si difieren, el desarrollador no usó el formato correcto y el servidor podría rechazar el envío. Esto forzaría a sus desarrolladores a solo empujar el código con el formato deseado, lo que los alentaría a escribir código limpio desde el principio, haría a los desarrolladores responsables de haber probado el código correctamente formateado y evitaría que sus desarrolladores tuvieran que instalar manualmente un lado del cliente. gancho.

Es un intercambio 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 se le echa la culpa de entender lo que está pasando. Si está trabajando en algo nuevo y no tiene que mantener la compatibilidad con versiones anteriores, el historial generalmente no juega un papel tan 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) en la función de confirmación, que ejecuta el formateador de código en el código de confirmación 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) Ignora los cambios propuestos y confirma 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 qué tanto quiera impulsar estos estándares de codificación) es que el sistema le envíe un informe de algún tipo cuando se selecciona la opción 2

Este puede ser un buen equilibrio entre la comprobación automática de todos los códigos que desee, y al mismo tiempo permite que los desarrolladores se adapten a sus necesidades. También permite la opción de no rechazar automáticamente el código con las diferencias de formato como se menciona en otras respuestas. Con el 'He revisado y aprobado correcciones automáticas de formato; Opción de compromiso, sigue manteniendo la responsabilidad personal para cada trabajo de los desarrolladores 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 yo 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 combinaciones se simplificarían significativamente ya que las cosas no van a saltar.

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

Otro lugar donde lo haría es tenerlo como parte de la compilación. En mi caso, lo tengo tal que maven builds reformateará el XML y limpiará los archivos pom y reformateará el código.

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