¿Es una buena idea formatear el código en eclipse usando el formato automático?


20

Uso eclipse para codificar, y el lenguaje que usamos es Java. Una vez fue sugerido por alguien que formatear correctamente el código, utilizando el formateador automático (CTRL + MAYÚS + F) Mientras este comando formatea el código, pero a veces siento que el aspecto general se vuelve extraño, y en realidad no es muy legible.

Entonces, ¿es esto algo recomendado? Si no, ¿cuál es el mejor formato de nuestro código en eclipse?


Uso la capacidad de formateo automático de emacs todo el tiempo: hay posibilidades de colisiones (por ejemplo, con la fusión de SC) ... pero, en general, estandarizar su formato es extremadamente útil
Warren

Respuestas:


34

Las reglas estrictas de formato de código son útiles cuando varios desarrolladores trabajan en el mismo código utilizando un sistema de control de versiones. La fusión puede ser un problema si diferentes desarrolladores tienen diferentes reglas de formato, ya que el mismo código se vería diferente para la herramienta de fusión.

Eclipse (o cualquier buen IDE para el caso) tiene reglas de formato de código que se pueden personalizar en la sección de preferencias (Java> Estilo de código> Formateador). Elija lo que más le guste, pero también eche un vistazo a las convenciones de código estándar de Java . Muchos proyectos de código abierto también tienen sus propias convenciones de código que se pueden aplicar con el formateador Eclipse.

Además, existen herramientas estándar como CodeStyle, PMD y Findbugs que imponen reglas adicionales y ayudan a evitar errores y patrones comunes (de bajo nivel).


44
Una vez que haya configurado su formateador de la manera que le gustaría. Hay un botón "Exportar" que le permitirá guardarlo en un archivo .xml. Ponemos esto en nuestro repositorio SVN, para que todos tengan acceso a él cuando revisen el proyecto.
Chris

Estoy de acuerdo con esto, y uso PMD y FindBugs y todo. Pero esto solo es una buena idea si todos en el equipo siguen y usan las reglas de formato de código. De lo contrario, terminará con commits que son cambios + formateo de algunos desarrolladores y no de otros, y es difícil ver los cambios "reales". En otras palabras, si el código anterior no está formateado con el formateador automático, no lo formatee con cambios adicionales en una confirmación.
Mufasa

2
Si personaliza la configuración de formato de código, inserte esas configuraciones en el control de origen para que todos los desarrolladores las obtengan, o publíquelas en algún tipo de wiki o documentación del desarrollador para que todos puedan acordar el estilo.
Mufasa

24

He encontrado el autoformatter muy útil. En lugar de tomar constantemente microdecisiones sobre cómo se debe formatear el código, algo que es propenso a errores y causa "fricción cognitiva", puede configurar reglas de formato y dejar que Eclipse formatee el código por usted (idealmente usando automáticamente "Guardar acciones" ) Por supuesto, esto requiere que tenga una base de código con un formato consistente, o que tenga el mandato de reformatear el código de acuerdo con las reglas que configure.

Tener habilitado el "autoformato al guardar" es un poco como tener una compilación incremental, le permite a su cerebro mantenerse enfocado en el código en sí mismo, en lugar de preocuparse por cuestiones triviales como el formato o la sintaxis del código.

Pero sí, a veces el autoformatter estropeará alguna tabla bien formateada que tenga. En tales casos, uso "etiquetas de encendido / apagado". Estos se configuran en la pestaña "etiquetas de encendido / apagado" en el perfil de formato de código. Al usarlos, puede excluir las regiones en su código de formatearse automáticamente:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

55
+1: Nunca supe (o para ser más exactos, nunca me molesté en averiguar sobre) las etiquetas de encendido / apagado.
Paul Cager

1
Autoformat-on-save es bueno si todos en el proyecto lo usan. Si solo algunos desarrolladores lo usan, entonces es demasiado fácil confirmar los cambios con cambios de formato de código al mismo tiempo, lo que hace que sea difícil encontrar los cambios "reales" en una confirmación.
Mufasa

@ Mufasa Sí, tienes razón.
JesperE

1
Cuando no desee formatear un comentario, puede escribir / * - mi súper formato * / Eclipse no formatea dicho comentario :)
Dawid Drozd

5

Si se recomienda o no dependerá de a quién le pregunte.

Me imagino que preferiría formatear el código usted mismo, después de todo, sabe lo que es mejor y más fácil de leer por sí mismo. En el lado positivo, si eres una persona considerada, también puedes hacerlo más legible para otros seres humanos.

Las máquinas no tienen ese tipo de previsión, y pueden (tal como dijiste) hacer que tu código parezca un poco desordenado, incluso si lo formatean con reglas estrictas.

Un buen IDE o herramienta a menudo puede hacer un trabajo semidecente al formatear el código por usted, pero no siempre lo hará lo más legible posible.

Entonces, mi consejo: no lo use a menos que reciba código de otra persona, y es un desastre que no puede leerlo de otra manera.


5

Debe usarlo todo el tiempo para asegurarse de usar un estilo consistente en todos sus archivos fuente. Esto también le ahorrará mucho tiempo, que generalmente pasaría tratando de ajustar el formato manualmente.

El formateador Java en Eclipse hace un trabajo bastante bueno y es completamente personalizable. Si no está de acuerdo con la configuración predeterminada (que puedo entender completamente), entonces debe ajustar el formateador a su preferencia de estilo personal o al estándar que utilice. Puede hacerlo en las preferencias de Java / Code Style / Formatter.

Los formateadores son aún más útiles cuando no está trabajando solo. Es muy probable que usted y los miembros de su equipo no estén de acuerdo con lo que cree que es el código perfecto style ™. En ese caso, debe aceptar una base común y de una vez por todas definir las reglas del formateador para este estilo de código en particular. Entonces todos pueden presionar el atajo de formato y todo se ajusta al estilo acordado. De esa manera, su preferencia personal (al escribir) no se interpondrá en el camino. Y tenga en cuenta que el estilo del formateador se puede almacenar en los archivos de proyecto de Eclipse, por lo que también son posibles diferentes formateadores para cada proyecto.


0

Aunque me gusta tener el código formateado automáticamente al guardar (de hecho, lo habilité en mis proyectos personales). Descubrí que no podía recomendar completamente esta práctica en equipos de proyecto que usan productos basados ​​en Eclipse, ya que el formateador de Eclipse tiene algunos errores críticos que me impiden recomendarlo.

Específicamente, si tiene habilitada la "limpieza de código" + "formateador", las sangrías se arreglan / desbloquean en cada guardado.

Cada nueva versión de Eclipse puede cambiar el formateador (para mejor), pero introduciría cambios significativos, como JavaDocs, que finalmente elimina ese espacio adicional después del *pero que se introdujo en algún momento después de que Helios y muchas empresas están utilizando la versión anterior de eclipse de Rational Software que usa Helios como base.

El formateador de código que proporciona Eclipse no es extensible por su API, de hecho, establece explícitamente CodeFormatter javadoc

Esta clase no está destinada a ser subclasificada por clientes.

Por supuesto, todavía no he encontrado ninguna alternativa no comercial viable . Jalopy no se ha actualizado durante años y los tenedores en github aún no están organizados para hacerme recomendar ninguno de ellos. Tampoco tiene ningún sitio de actualización para que Eclipse lo tenga integrado. En realidad, estaba planeando hacer el formateo del código como parte de la compilación, al igual que lo hice cleanpom-maven-plugin usando Jalopy, pero esa idea quedó en el camino debido a la falta de actualizaciones para Jalopy.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.