¿Cómo desactivar el formateador de código Eclipse para ciertas secciones del código Java?

489

Tengo un código Java con sentencias SQL escritas como cadenas Java (por favor, sin llama OR / M, el SQL incorporado es lo que es, no es mi decisión).

He dividido semánticamente las declaraciones SQL en varias cadenas concatenadas en varias líneas de código para facilitar el mantenimiento. Entonces, en lugar de algo como:

String query = "SELECT FOO, BAR, BAZ FROM ABC WHERE BAR > 4";

Tengo algo como:

String query =
    "SELECT FOO, BAR, BAZ" +
    "  FROM ABC          " +
    " WHERE BAR > 4      ";

Este estilo hace que el SQL sea mucho más fácil de leer y mantener (en mi humilde opinión), especialmente para consultas más grandes. Por ejemplo, puedo poner mi editor en modo "sobrescribir" y modificar el texto en el lugar con bastante facilidad.

Tenga en cuenta que este problema se generaliza más allá del ejemplo particular de SQL. Cualquier código que esté escrito con cualquier formato vertical, particularmente construcciones tabulares, es susceptible de ser destruido por una bonita impresora.

Ahora, algunos miembros del proyecto usan el editor Eclipse y el formato semántico a menudo se destruye cuando formatean un archivo fuente completo.

¿Hay alguna manera de indicarle a Eclipse que ignore ciertas líneas de origen con respecto al formato?

Estoy buscando algo así como un comentario especial que alterna el formateador Eclipse. Idealmente, dicho comentario podría ser configurable para que sea lo que elijamos, y otros formateadores también podrían programarse para respetarlo:

// STOP-ECLIPSE-FORMATTING
String query =
    "SELECT FOO, BAR, BAZ" +
    "  FROM ABC          " +
    " WHERE BAR > 4      ";
// START-ECLIPSE-FORMATTING

Obviamente, una "solución" es hacer que los miembros de nuestro equipo se estandaricen en algún formateador externo como Jalopy o JIndent , pero de eso no se trata esta pregunta (tampoco de mi decisión sobre este proyecto): específicamente estoy buscando una manera de evite el formateador de Eclipse sobre una base ad-hoc.

Idealmente, una solución me permitirá insertar instrucciones para el formateador de Eclipse sin requerir que los miembros del equipo que utilicen Eclipse realicen ninguna reconfiguración IDE (además de posiblemente elegir un comentario de comando agnóstico del formateador: STOP-ECLIPSE-FORMATTINGSTOP-FORMATTING).

Greg Mattes
fuente
1
Hemos tenido este problema. Eclipse debería tener una opción para siempre romper una línea en un constructor de cadenas donde está un +, independientemente de si el siguiente bit de cadena encajaría en la línea. Pero no lo hace. :-(
JeeBee
Aparentemente, esta característica se agregó en Eclipse 3.6M6: bugs.eclipse.org/bugs/show_bug.cgi?id=27079
Guillaume
Nota: Si simplemente desea evitar que eclipse altere sus comentarios, puede usar // delante de cada línea. Para comentar un bloque, resalte y presione Ctrl + /.
John Henckel
Tenga en cuenta que ahora, 10 años después, Java 14 probablemente traerá cadenas de varias líneas haciendo que esto sea cosa del pasado.
Thorbjørn Ravn Andersen

Respuestas:

866

Eclipse 3.6 le permite desactivar el formato colocando un comentario especial, como

// @formatter:off
...
// @formatter:on

Las funciones de encendido / apagado tienen que ser en "ON" en las preferencias de Eclipse: Java > Code Style > Formatter. Haga clic en Edit, Off/On Tags, habilite Enable Off/On tags.

También es posible cambiar las cadenas mágicas en las preferencias: consulte los documentos de Eclipse 3.6 aquí .

Más información

Java > Code Style > Formatter > Edit > Off/On Tags

Esta preferencia le permite definir una etiqueta para deshabilitar y una etiqueta para habilitar el formateador (consulte la pestaña Etiquetas de Apagado / Encendido en su perfil de formateador):

ingrese la descripción de la imagen aquí

También debe habilitar las banderas de Java Formatting

xpmatteo
fuente
77
La opción "Nunca unir líneas" que se menciona en otra parte de esta página también es muy útil.
xpmatteo
89
Las funciones de encendido / apagado tienen que estar "activadas". En las preferencias de Eclipse: Java> Estilo de código> Formateador. Haga clic en el botón "Editar", "Etiquetas de apagado / encendido", marque "Habilitar etiquetas de encendido / apagado".
Domenic D.
2
Esto no está disponible en las preferencias de JavaScript Code Style , donde tengo exactamente el problema opuesto con el formateo. :(
Redsandro
11
Los equipos deben exportar una copia de las preferencias (archivo) de Eclipse a su wiki y exigir que todos usen la misma. Funciona bien para nosotros. ;)
Joseph Lust
Para su información, tuve que eliminar el espacio entre el // y el signo @ para que esto funcione.
Roy Truelove
61

AFAIK de Eclipse 3.5 M4 en el formateador tiene una opción "Nunca unir líneas" que preserva los saltos de línea del usuario. Tal vez eso hace lo que quieres.

De lo contrario, está este truco feo

String query = //
    "SELECT FOO, BAR, BAZ" + //
    "  FROM ABC"           + //
    " WHERE BAR > 4";
estar nervioso
fuente
1
Entonces, además de configurar la opción "Nunca unir líneas", ¿ también tengo que escribir estos comentarios "fantasmas"? ¿No debería funcionar la parte "Nunca unir líneas" por sí sola?
Greg Mattes el
2
Sí, claro que debería. Los comentarios fantasmas son un enfoque alternativo (en caso de que no exista, o que tenga una versión anterior, etc.).
Chris
He usado este enfoque en conjunto con una plantilla de formato personalizada en TOAD para permitirme quitar el viejo SQL del código JAVA, reformatearlo y obtener todos los comentarios extraños y luego volver a arrojarlo a JAVA. Es una molestia, pero ahora nos permite formatear automáticamente al guardar nuestro código Java. ¡Gracias por la sugerencia!
jnt30
Sin marcar la opción "Nunca unir líneas", las macros de encendido / apagado no funcionan para mí, ¡gracias!
Christoffer Soop
28

Ver esta respuesta en SO .

Hay otra solución que puede usar para suprimir el formato de comentarios de bloque específicos. Use /*-(observe el guión) al comienzo del comentario de bloque, y el formato no se verá afectado si formatea el resto del archivo.

/*-
 * Here is a block comment with some very special
 * formatting that I want indent(1) to ignore.
 *
 *    one
 *        two
 *            three
 */

Fuente: Documentación en Oracle .

Renaud
fuente
2
Esta es la mejor respuesta, ya que no depende de la configuración del IDE del usuario. Gracias.
Azim
26

En lugar de desactivar el formato, puede configurarlo para que no se una a las líneas ya ajustadas. Similar a la respuesta de Jitter, aquí está para Eclipse STS:

Propiedades → Estilo de código Java → Formateador → Habilitar ajustes específicos del proyecto O Configurar ajustes del espacio de trabajo → Editar → Ajuste de línea (pestaña) → marque "Nunca unir líneas ya ajustadas"

Guardar, aplicar.

ingrese la descripción de la imagen aquí

ilinca
fuente
1
Creo que esto ayudaría para cosas como el ejemplo de SQL, pero no estoy seguro de que sea suficiente para el caso general de deshabilitar completamente el formateador IDE.
Greg Mattes
2
Esta solución es excelente cuando se usa el patrón de construcción y su relevancia ciertamente aumenta con la introducción de lambdas en Java 8.
Jonas Kongslund
16

Debe activar la capacidad de agregar las etiquetas de formateador. En la barra de menú vaya a:

Windows Preferences Java Code Style Formatter

Presiona el Editbotón. Elige la última pestaña. Observe la casilla de encendido / apagado y actívelos con una casilla de verificación.

ZilWerks
fuente
14

Si coloca el signo más al comienzo de la línea, se formatea de manera diferente:

String query = 
    "SELECT FOO, BAR, BAZ" 
    +    "  FROM ABC"           
    +    " WHERE BAR > 4";
CPerkins
fuente
1
Esto podría ser un compromiso interesante. En general, me gustaría abstenerme de cambiar demasiado el formato del código debido a un comportamiento indeseable de una herramienta. En este caso, los operadores de concatenación de cadenas son más un accidente que la esencia de lo que sucede con el SQL. Es por eso que prefiero escribirlos al final de cada línea. Siento que el SQL debe enfatizarse como el comienzo de la línea. Pero esta puede ser una buena forma de hacerlo en ausencia de una solución que me permita conservar el formato deseado. ¡Gracias!
Greg Mattes el
8
De nada. En realidad, he estado poniendo mis signos + al frente de las líneas durante décadas, y no para engañar al formateador. Los prefiero al frente, porque aclara lo que me sucede: lo que está al final de una línea a veces se pierde. Era el estándar del proyecto en algún lugar cuando utilizamos compiladores de leña, y me quedó grabado.
CPerkins 01 de
5

Estoy usando partes de cadena de ancho fijo (rellenadas con espacios en blanco) para evitar que el formateador estropee mi sangría de cadena SQL. Esto le brinda resultados mixtos y no funcionará donde no se ignore el espacio en blanco como en SQL, pero puede ser útil.

    final String sql = "SELECT v.value FROM properties p               "
            + "JOIN property_values v ON p.property_id = v.property_id "
            + "WHERE p.product_id = ?                                  "
            + "AND v.value        IS NOT NULL                          ";
Guus
fuente
5

Termine cada una de las líneas con una barra doble "//". Eso evitará que el eclipse los mueva a todos en la misma línea.

Evvo
fuente
4

Método alternativo: en Eclipse 3.6, en "Ajuste de línea" y luego en "Configuración general" hay una opción para "Nunca unir líneas ya ajustadas". Esto significa que el formateador envolverá líneas largas pero no deshacerá ningún ajuste que ya tenga.

kmccoy
fuente
4

@xpmatteo tiene la respuesta para deshabilitar porciones de código, pero además de esto, la configuración de eclipse predeterminada debe establecerse para formatear solo las líneas de código editadas en lugar de todo el archivo.

Preferences->Java->Editor->Save Actions->Format Source Code->Format Edited Lines

Esto habría evitado que sucediera en primer lugar ya que sus compañeros de trabajo están formateando el código que en realidad no cambiaron. Esta es una buena práctica para evitar contratiempos que hacen que la diferencia en el control de su fuente sea inútil (cuando se formatea un archivo completo debido a diferencias menores en la configuración del formato).

También evitaría el formateo si la opción de etiquetas de encendido / apagado estaba desactivada.

Robin
fuente
2

¡Los comentarios fantasmas, que agregan //donde quieres nuevas líneas, son geniales!

  1. @Formatter: off agrega una referencia del código al editor. El código debería, en mi opinión, nunca tener tales referencias.

  2. Los comentarios fantasma (//) funcionarán independientemente de la herramienta de formato utilizada. Independientemente de Eclipse o InteliJ o cualquier editor que use. Esto incluso funciona con el muy agradable formato Google Java

  3. Los comentarios fantasmas (//) funcionarán en toda su aplicación. Si también tiene Javascript y quizás use algo como JSBeautifier . Puede tener un estilo de código similar también en Javascript.

  4. En realidad, probablemente quieras formatear, ¿verdad? Desea eliminar tabuladores / espacios mixtos y espacios finales. Desea sangrar las líneas de acuerdo con el código estándar. Lo que NO quieres es una larga cola. ¡Eso, y solo eso, es lo que te da el comentario fantasma!

Tomás Bjerre
fuente
-3

Este truco funciona:

String x = "s" + //Formatter Hack
    "a" + //
    "c" + //
    "d";

Sugeriría no utilizar el formateador. El código incorrecto debe verse mal, no artificialmente bueno. El buen código lleva tiempo. No puedes engañar a la calidad. El formateo es parte de la calidad del código fuente.

Thomas Jung
fuente
8
No usar el formateador es solo una mala idea; El formateador ayuda a detectar errores y mantiene el código en un estado coherente.
Francis Upton IV
Una sugerencia interesante, pero no veo cómo el formato nos dice si el código es bueno o no.
Chris
2
Creo que lo que dice es que siente que el código mal escrito y mal formateado debe mantenerse tal cual en lugar de formatearlo con la esperanza de "mejorarlo". El código mal escrito y mal formateado debería "sobresalir" de alguna manera para que pueda identificarse fácilmente. No estoy seguro de estar totalmente de acuerdo, pero creo que esa es la idea.
Greg Mattes el
1
@Francis - Bugs: ¿Cómo puede el código formateado automáticamente encontrar errores? Consistencia: la consistencia es un buen argumento, pero la calidad general del código es más importante. Puede definir un buen proceso consistente para voltear hamburguesas, pero nunca funcionará para la alta cocina. Cocinar puede ser una actividad razonablemente complicada o trivial si ignora suficientes hechos. Si crees que el desarrollo de software es como las herramientas de volteo de hamburguesas que imponen la coherencia son para ti. Este no es un argumento en contra de las líneas de guía de formato, pero si a los desarrolladores no les importan estas pautas, no se preocuparán por otros elementos esenciales.
Thomas Jung
44
Mi argumento aquí: escribo un buen código y me apego a las líneas de guía de formato. Pero soy perezoso. ¿Por qué debería insertar la cantidad correcta de espacios y saltos de línea cuando puedo escribir mis cinco líneas de código descuidado, presionar el botón de formato y estar feliz? DESPUÉS de haber formateado el código, usando mi herramienta que asegura que el resultado sea siempre perfecto, soy tan nazi como cualquiera sobre el formato. NO hay argumento en contra de apegarse a las líneas de guía (aparte de que pueden ser particularmente malas) si el formato está a solo un golpe de distancia. Todos los miembros del proyecto comparten la misma configuración de formato de código.
Por Wiklander