Ventajas y desventajas del reformateo de código forzado

19

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.

Nerdfest
fuente
JSP auto-reformateado? Eso incluye código HTML / XML y reformateo que puede romper / cambiar muy fácilmente el resultado resultante.
edA-qa mort-ora-y

Respuestas:

23

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.

bohemio
fuente
1
Estoy de acuerdo en morder la bala en un cambio global es realmente la mejor manera; hazlo y nadie tiene que preocuparse por eso nunca más.
Patrick Hughes
... hasta que cambies tu convención de estilo.
Nerdfest
1
@Nerdfest Luego, aplica su nueva convención en todos sus proyectos en una sola confirmación. Eso no es gran cosa.
gizmo
2
Su herramienta "diff" es un asco si no puede manejar los cambios de espacio en blanco correctamente.
edA-qa mort-ora-y
2
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.
edA-qa mort-ora-y
10

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.

Nerdfest
fuente
Una convención de formateo sobre otra rara vez ofrece algún beneficio si se produce a expensas de la coherencia. Te acostumbras. Siga los consejos de Bohemian y cree un período de gracia para ayudar a determinar los estilos de formateo y luego seguir con ellos. Cambiar el formato no debe tomarse a la ligera de todos modos.
JeffO
3
@Jeff, no creo que esté abogando por un formato de código inconsistente, sino un formato de código consistente que es difícil de automatizar. Por ejemplo, muchos estilos de codificación especifican columnas de alineación de una manera estética cuando tiene varias líneas de datos relacionados juntos. Esto mejora en gran medida la legibilidad, pero es muy difícil automatizar las definiciones de "estético" o "relacionado". Esa es la razón por la cual algunos formateadores de código permitirán anular el formateo manual bajo ciertas circunstancias.
Karl Bielefeldt
1
Es mucho mejor tener un formato consistente el 99.9% del tiempo y aguantar la parte extraña que a usted personalmente no le gusta, que soportar una misma falta indisciplinada. Probablemente dependa de cuán disciplinado sea el equipo donde reside el equilibrio. Si se apega a las normas establecidas para un idioma, todos los editores / IDE decentes serán capaces de formatear de esa manera. Si insiste en moverse de las normas, tendrá problemas.
mattnz
3

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.

Woot4Moo
fuente
3

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.

SF.
fuente
Esto es un desastre, mi cerebro positrónico se derritió. Tanta inconsistencia con los espacios en blanco alrededor (y). Eso es exactamente por qué necesitamos máquinas para formatear el código. Y siempre puede poner un comentario de una sola línea antes / después (depende de su convención) para forzar la agrupación de condiciones. También sería útil explicarle al lector las reglas comerciales detrás de estas condiciones, justo en los comentarios de esta línea.
Štefan Oravec
@ ŠtefanOravec: Ejecute esto a través de un autoformatter y aplique estos comentarios. Vea si es más legible. Usuario de prueba, siempre. Usuarios humanos con nombres de usuario válidos. Usuarios emulados: solo fuentes externas. El correo electrónico, si está presente, debe ser válido. Los usuarios humanos deben tener un número de teléfono; emulado, no debe. Vea cómo se alinean sus comentarios de una sola línea con el código autoformatado.
SF.
2

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.

Nerdfest
fuente
0

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

Thomas
fuente
Eso es más una cuestión de estilo de código, no una cuestión de formato. Hay herramientas de construcción para eso.
@Bohemian, tienes razón, leí mal la pregunta. La herramienta de construcción de nuestra elección es checkstyle por cierto. :)
Thomas
0

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.

talnicolas
fuente
0

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.

pie azul
fuente
0

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.


fuente