Código de formato automático

Question

Nuestro equipo ha heredado recientemente el código que es extremadamente desorganizado.

Como resultado, el líder de mi equipo ha decidido aplicar una política de auto-formateo de código antes de guardar un archivo. Incluso hemos encontrado una opción en Eclipse (el IDE de nuestra elección) que formatea automáticamente el código automáticamente antes de cada acción de guardado.

Personalmente, estoy en contra de eso porque creo que una codificación adecuada evita el código desordenado (la mayoría de las veces) mientras que el auto-formateo no significa una codificación adecuada.

¿Cuáles son sus opiniones?

Answer 1

Auto-formatee el código heredado solo una vez, y luego continúe sin formatear automáticamente.

Answer 2

No estoy de acuerdo con usted. Para mí, el formateo, incluso si solo es una forma de "presentar" el código fuente, también es un importante indicador de calidad del código.

El uso del formateado automático tiene varias ventajas. Homogeneiza el formato entre todos los desarrolladores del equipo. Esto evitará algunos problemas con la manipulación de SCM: por ejemplo, combinar dos archivos que tienen pocos cambios reales, pero ¡muchas diferencias de formato son una pesadilla!

También puede mostrar algunos errores. Por ejemplo:

if (aCondition) 
    foo(); 
    bar(); 

tendrá un nuevo formato:

if (condition) 
    foo(); 
bar(); 

mostrando que la segunda línea es no en la declaración if.

Por último, pero no menos importante, ¡un código bien formateado (no solo para Java) es más fácil de leer!

Answer 3

En mi opinión, el formato de código coherente mejora la legibilidad. Claramente, no es un sustituto del buen código, pero, por otro lado, el constructo más brillante que tiene un formato descuidado tampoco puede llamarse buen código.

El problema con el auto-formato para mí es que altera el sistema de control de versiones. Sin embargo, una conversión única de formato, sin ningún otro cambio, puede mejorar el flujo de trabajo.

Answer 4

En realidad, utilizamos el auto-formateo en eclipse y, a menudo, hace que mi código sea menos legible, por ejemplo al insertar en muchos saltos de línea. Y a medida que migramos a una nueva versión de eclipse, el formato no era el mismo aunque usamos la misma configuración. Esa es una gran desventaja en combinación con un sistema de control de versiones. Prefiero el complemento CheckStyle para lograr un estilo de código consistente.

Pero como dije, usaría autoformato una vez cuando refactoreé un archivo.

Answer 5

El único problema que se me ocurre al habilitar el formateado automático en Eclipse es que si está utilizando el control de fuente (ESTÁ usando el control de fuente, ¿verdad?), Las diferencias serán enormes y posiblemente dificultará descifrar qué fue un cambio de código real versus un cambio de formato.

Dicho esto, tener un código bien formateado es fundamental para escribir software sólido.

Answer 6

Un formato de código consistente realmente ayuda con la diferencia y tal al enviar el código.

He configurado mis scripts de control de fuente para que se auto-formateen a 'estilo de casa' cuando presiono y auto-formateo a mi estilo preferido al tirar, para que todos estén contentos.

Te recomiendo que consideres lo mismo.

Answer 7

Depende de lo que quiere decir con "desorganizado". ¿Estamos hablando de inconsistencias estilísticas, o la estructura de clases es un hight-podge ininteligible? Supongo que lo primero si lo estás tratando a través de un formateador automático.

"Correcta codificación" no significa necesariamente "coherente entre los desarrolladores". Si tengo mi editor configurado en pestañas duras de cuatro espacios y tiene las suyas configuradas en pestañas suaves de tres espacios, el código en el que ambos trabajamos se verá como un asno. (Y nuestro gerente de proyecto probablemente nos golpee a los dos al revés y déjenos saber qué estándar DEBERÍAMOS usar).

El formateador automático es una solución de fuerza bruta y se garantiza que ocasionalmente se convierta en algo inusual pero perfectamente legible en un lío. Si el código es realmente un desastre, es un punto de partida sensato. Pero una vez que haya formateado automáticamente la mayor parte de Suck del código preexistente, será mejor que establezca las convenciones de estilo preferidas del equipo y continúe desde allí.

Answer 8

Creo que el formato de su código es importante. Los ejemplos brindados resaltan el potencial de cometer errores tontos como ese, ¡aunque usaría el ejemplo para argumentar que siempre use los frenos!

Me parece que tiene que trabajar más duro para entender el código cuando se buscan archivos de origen que tienen una variedad de formatos diferentes. Los patrones de código regulares facilitan la comprensión de la semántica porque las declaraciones están todas "en el lugar correcto".

No estoy seguro de qué se entiende por "codificación adecuada", ya que parece un poco ambiguo en cuanto a lo que constituye "adecuado". Hay construcciones de lenguaje que probablemente nunca deberían usarse en circunstancias normales y anti-patrones de ingeniería de software que deberían evitarse. Si estas cosas son lo que se entiende por codificación adecuada, asegúrese de que estas cosas sean importantes, pero no se reflejan en el formato del documento del archivo fuente.

Existen herramientas para forzar el formato del código dentro de un archivo fuente mediante la violación de las fallas de compilación de formato. Al principio, era escéptico con respecto a estas herramientas, ya que parecen un poco draconianas, pero descubrí que tener la estructura de código uniforme es una verdadera mejora en la productividad.

P.S. Última declaración completamente anecdótica ya que no tengo métricas para respaldarlo.

Answer 9

código de formateo es extremadamente importante:

• Al mantener el código correctamente sangría, la navegación a través de archivos de tamaño medio o grande puede ser más fácil para el usuario.
• Al mantener un estilo de codificación constante en todos los proyectos, cuando las personas se trasladan a otros proyectos estarán más familiarizados con el código. Por supuesto, esto también está relacionado con las pautas de codificación, cómo nombrar variables, etc. que también debería ser relativamente normalizado en un terreno común.
• Si pasa algún tiempo haciendo las reglas adecuadas de formato de código, también garantiza que el código puede ser visto por más usuarios (tuve que editar el código a mano en un texto [creo que notepad o emacs] a mano muchas veces, desafortunadamente.Mediante el establecimiento de una longitud de fila de 80 cols o lo que puede ayudar)
• más importante, manteniendo un formato coherente puedes diferencia de dos archivos mucho más fácil

Answer 10

Estoy con el líder de su equipo en este caso y tengo dos sugerencias para usted:

1. guardar cada archivo una vez que el único cambio es el formato con un cometer mensaje que refleja que esto era todo lo que ha cambiado, la n vaya atrás y haga su código actual cambios. Esto le ahorrará mucho de tiempo cuando necesite modificar cambios. La revisión de formato será tiene casi todas las líneas de código cambiado, por lo que será prácticamente imposible para encontrar un cambio real en la misma revisión.

2. Acepte un estándar de codificación y personalice la herramienta de auto-formato de Eclipse para seguir ese estándar.

Answer 11

I, como líder del equipo de desarrollo, estoy en contra del formateo automático. Debido a que el código legible es importante, es importante que los desarrolladores responsables puedan formatear su código como lo consideren necesario. Los formateadores automáticos pueden arruinar los comentarios cuidadosamente elaborados, eliminarán las líneas en blanco adicionales insertadas para mayor claridad, etc.

Usamos complementos como checkstyle con un conjunto de reglas estándar que debe cumplirse, el código marcado no debe tener advertencias de estilo de control . Si aparece algún código no estructurado, el formateador de eclipses puede realizar la primera limpieza y comprobar el estilo y los amigos señalan los problemas pendientes de resolver.

Answer 12

En su carrera, se espera que siga los estándares de cada compañía individual. Eso significa que la mayor parte del tiempo puede no estar de acuerdo con la política.

Gimotear acerca de tener que usar un estándar de la compañía para el formateo automático no es profesional y en última instancia es malo para la forma en que su jefe y sus superiores lo ven, ya que pensarán que no es un jugador de equipo. Se acostumbrará a lo que sea que sea el formato estándar, sin importar cuán lejos esté de lo que le gustaría y, algún día, cuando sea el administrador, puede elegir cómo se realizará el formateo. Mientras tanto, no es su decisión (usted no es el propietario de la base de códigos, la empresa sí) y debe hacer lo que se le solicitó.

Si tiene algunos ejemplos válidos de cómo el autoformato hace que el código sea más difícil de leer, puede compartirlos con su jefe, pero honestamente, esta es una pelea que probablemente no gane y simplemente lo hace quedar mal para intentarlo .