Ventajas y desventajas del reformateo de código forzado

Actualmente estoy trabajando en un lugar que podría estar buscando forzar a los desarrolladores a usar un formateador de código automático en el control de versiones. Estoy buscando opiniones de los desarrolladores sobre las ventajas y desventajas de hacer esto ... cómo crees que ayudaría u obstaculizaría a los desarrolladores. Mi caso específico involucra Java / JSP, pero creo que la pregunta podría aplicarse a cualquier lenguaje.

Creo que es muy importante hacer esto. Este es el por qué:

• Hace que sus diferencias de control de fuente muestren solo los cambios reales del código, y elimina el "ruido de diferencias" debido al espacio en blanco y otras opciones de formato insignificantes
• Hace que todo el código sea más similar, para que los desarrolladores se sientan más cómodos emparejando y compartiendo las bases del código

Si lo hace, recomendaría a todos que revisen todo el código, luego una persona hace un reformateo en toda la base del código, luego lo vuelve a verificar para que haya un conjunto de cambios "gigantes" para formatear (que todos pueden ignorar), pero después de eso, todas las diferencias son diferencias de código real.

Si lo hace poco a poco, estará mezclando cambios de código real con cambios de formato y las cosas se volverán innecesariamente desordenadas en el terreno del cambio.

Voy a arrojar mi propia respuesta aquí, ya que las personas solo parecen estar agregando ventajas. Lo que veo como desventajas son:

• Elimina la capacidad de hacerlo 'mejor' que el formateador automático ... deshacerá su formateo más limpio. Un ejemplo de esto serían las declaraciones de parámetros basadas en columnas, listas de adiciones discretas de objetos, etc.
• Crea una resistencia a cambiar las convenciones de estilo ya que ahora crearán grandes cambios de diferencias engañosos.
• Elimina la capacidad de hacer cualquier formato de 'caso especial' donde un formato alternativo haría que el código sea más legible.
• Lo vincula con el uso de IDE que admiten exactamente las características de reformateo que necesita. En otro IDE falta una de las opciones que necesita, causará al menos algunos problemas.
• Se vuelve problemático compartir un repositorio de código grabable con un grupo externo a menos que usen exactamente las mismas convenciones de formato que su grupo (generalmente lo harán, pero no siempre).
• Siempre habrá excepciones en las que un formato ligeramente diferente sea más limpio que el estilo prescrito. Por lo tanto, la conversión automática a menudo puede ocultar la intención de ciertos bloques de código, lo que efectivamente es tan bueno como agregar un defecto al código.

En pocas palabras, un conjunto de convenciones no automatizado establece requisitos mínimos de estilo / legibilidad, donde las convenciones automatizadas establecen un mínimo y un máximo.

Recuerdo haber visto VB (quizás la versión 5) y encontrar una de las cosas más molestas al respecto era que reformatearía mi código a la fuerza y ​​eliminaría las cosas más allá de su formato básico.

Me parece que el formato de código forzado es genial. Permite a un desarrollador atravesar todo el corpus de código sin que sus ojos reboten en todas partes. Tener este estándar también ayuda a los desarrolladores novatos a romper los malos hábitos.

La desventaja principal es perder el formato personalizado donde realmente importa.

Imagine una comprobación de cordura típica if () que fallará si alguna de las condiciones específicas está presente pero no se cumple ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Esto es legible gracias a una sangría razonable que sigue la estructura lógica de las condiciones.

Ahora su herramienta automatizada no tiene idea de la separación lógica de diferentes condiciones en líneas relacionadas. No ve ninguna razón por la cual cada grupo 3-4 condiciones en una línea y divide la siguiente condición por la mitad. O lo dividirá, una expresión de comparación por línea. Incluso puede parecer más bonito en la pantalla, pero se perderá la lógica.

He agregado una respuesta con desventajas, y también agregaré lo que considero una gran ventaja.

Cuando utiliza un reformateo de código automatizado en commit, en realidad abre la posibilidad de variaciones de preferencias personales sin el efecto habitual de que sus preferencias se inflijan a otros. Puede tener su código de formato IDE con un estándar común en commit, pero mostrárselo en su formato preferido sin afectar a los demás.

Esto para mí es casi el Santo Grial de la codificación basada en convenciones ... obtienes las ventajas de un formato de código común, pero aún así permites que las preferencias personales sean compatibles sin conflictos.

Depende de sus necesidades, pero algunas restricciones son bastante útiles, por ejemplo, cada if () debe ir seguido de llaves, ya que es bastante fácil obtener ese tipo de error si está refactorizando.

Considere ese caso:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Si ahora desea agregar algo de registro al caso if, puede escribir de forma accidental:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

Y de repente su método siempre regresa foo.

Editar: no se trata de formateo automático sino de verificación de estilo. Lo siento si esa respuesta también estuvo fuera de tema. :)

Ayuda en gran medida a uniformar el código en la empresa, y gracias a eso generalmente produce una estructura más fácilmente comprensible y más fácil de mantener para su producto.

Así, las ventajas son las mismas que cualquier formateador de código, como la estandarización del código, semántica entre los desarrolladores, etc. Las únicas posibles inconvenientes que veo es la falta de un ojo humano después del formateo, añadir algunas excepciones, etc.
, así que Supongo que es mejor considerar un formateador IDE en lugar de un formateador de tiempo de registro.

En mi experiencia, es algo bueno. Sin uno, las comparaciones de código a menudo muestran un desorden de formato de espacios en blanco y pueden ocultar cambios reales en el código. En mi experiencia, jugar con el formateo de alguien no es el pecado que se supone que es, especialmente con los beneficios potenciales de la coherencia en todo el equipo.