guidestyle - ¿Alguna razón para limpiar las importaciones no utilizadas en Java, aparte de reducir el desorden?
java guidestyle (11)
¿Hay alguna buena razón para evitar declaraciones de importación no utilizadas en Java? Según tengo entendido, están ahí para el compilador, por lo que muchas de las importaciones no utilizadas no tendrán ningún impacto en el código compilado. ¿Es solo para reducir el desorden y evitar conflictos de nomenclatura?
(Lo pregunto porque Eclipse da una advertencia sobre las importaciones no utilizadas, lo que es un poco molesto cuando estoy desarrollando código porque no quiero eliminar las importaciones hasta que esté bastante seguro de haber terminado de diseñar la clase).
¿Advertencia? Pídale a Eclipse que los limpie automágicamente por usted. Eso es lo que IntelliJ hace. Si es lo suficientemente inteligente como para advertirte, debe ser lo suficientemente inteligente como para limpiarlos. Recomiendo buscar un ajuste de Eclipse para decirle que deje de ser tan molesto y haga algo.
Desde un punto de vista purista, cualquier dependencia es una "restricción" en el producto y, por lo tanto, puede causar problemas de mantenimiento más adelante.
Por ejemplo, supongamos que su programa utiliza la clase com.XYZObjectPool, y que luego decide no usarla, pero nunca elimina la importación. Si alguien más ahora quiere crear una instancia de org.WVYObjectPool y solo hace referencia a ObjectPool, no recibe ninguna advertencia al respecto hasta que en algún momento haya un problema de conversión o de invocación.
Esto, por cierto, no es un escenario poco realista. Cada vez que Eclipse le preguntaba qué versión específica de X deseaba importar, y elegía uno de entre muchos paquetes, hay un escenario en el que, si realizó la importación allí, es posible que haya obtenido una elección incorrecta sin saberlo.
De cualquier manera, puede pedirle a Eclipse que lo limpie por usted
Esto tiene que ver con la claridad del programa útil para el mantenimiento.
Si tuviera que mantener un programa, encontrará lo útil que es tener una única clase importada por línea.
Piensa en la siguiente situación:
import company.billing.*;
import company.humanrerources.*;
// other imports
class SomeClass {
// hundreds or thousands of lines here...
public void veryImportantMethod() {
Customer customer;
Employee comployee;
Department dept.
// do something with them
}
}
Cuando está corregiendo errores o manteniendo una parte del código (o solo leyéndolo), es muy útil para el lector saber a qué paquete pertenecen las clases utilizadas. Usar la importación del comodín como se muestra arriba no ayuda para ese propósito.
Incluso con un IDE, no desea pasar el cursor sobre la declaración y regresar, es más fácil si comprende en términos de funcionalidad de qué otros paquetes y clases depende el código actual.
Si esto es para un proyecto personal o algo pequeño, realmente no importa, pero para algo más grande que tienen que ser utilizados por otros desarrolladores (y mantenido a través de los años) esto es DEBEN TENER.
No hay absolutamente ninguna diferencia de rendimiento con ninguno.
Leí en algún lado, hace algunos años, que cada clase importada se cargaría en tiempo de ejecución con la clase importadora. Por lo tanto, eliminar los paquetes no utilizados, especialmente todo, reduciría la sobrecarga de memoria. Aunque supongo que las versiones modernas de Java se ocupan de eso, probablemente ya no sea un motivo.
Y, por cierto, con Eclipse puede usar Ctrl + Shift + O para organizar las importaciones, pero también puede configurar un "limpiador" que maneje tales cosas (y muchas otras) cada vez que guarde un archivo java.
No creo que los problemas de rendimiento o algo similar sean posibles si no está eliminando las importaciones.
Pero podría haber conflictos de nombres, en casos raros como importar la interfaz de la lista.
En Eclipse siempre puede usar un acceso directo (depende de sistema operativo - Win: Ctrl + SHIFT + O y Mac: COMMAND + SHIFT + O ) para organizar las importaciones. Eclipse luego limpia la sección de importación elimina todas las importaciones obsoletas, etc. Si necesita una cosa importada, eclipse las agregará automáticamente mientras completa la declaración con Ctrl + SPACE . Así que no hay necesidad de mantener el código no utilizado en su clase.
Como siempre el código no utilizado lo distraerá a usted y a otras personas mientras lee el código y deja algo en su código activo porque tal vez lo necesite más tarde se lo considera una mala práctica.
No hay ningún impacto en el rendimiento, aunque para la legibilidad puede hacerlo limpio. La eliminación de importaciones no utilizadas es bastante simple tanto en Eclipse como en IntelliJ IDEA.
Eclipse
Windows / Linux - Ctrl + Shift + O
Mac - Cmd + Shift + O
IntelliJ IDEA o Android Studio
Windows / Linux - Ctrl + Alt + O
Mac - Cmd + Alt + O
Para eclipse utilizo esto: ventana -> preferencias -> java -> editor -> guardar acción -> marcar la casilla de verificación para organizar las importaciones (hay muchas otras cosas útiles allí también, como formatear, hacer que los campos sean definitivos, etc. .). Así que cuando guardo mi eclipse de archivo, quito las importaciones de desinfección para mí. En mi opinión, si no necesitas algo, quítalo (o deja que se elimine por eclipse).
Para mí, una importación de clase no utilizada en una clase de controlador creó un problema de compilación en la compilación de Jenkins después de que eliminé la clase importada durante la limpieza del código y cometí la eliminación en git sin probar una compilación en local.
Para tu información, esto me sorprendió, ya que no creía que las importaciones organizadas realmente eliminaran las importaciones no utilizadas, pensé que solo las había ordenado.
La eliminación automática de las importaciones durante una operación de salvar me causó cierta pena cuando, por ejemplo, durante el desarrollo o las pruebas tiene un problema y comenta un código, cuando lo guarda, las importaciones utilizadas por la sección de código comentada se eliminan. A veces esto no es un problema, ya que puede deshacer ( Ctrl + Z ) los cambios, pero otras veces no es tan simple, ya que puede haber hecho otros cambios. También tuve un problema donde cuando descomentaba el código (anteriormente comenté y luego lo guardé, eliminando así las importaciones para ese código), automáticamente intentaba adivinar las importaciones que se necesitaban y recogía las incorrectas (por ejemplo, creo que tenía una clase StringUtils uso y eligió otra con el mismo nombre de la biblioteca incorrecta).
Prefiero organizar manualmente las importaciones en lugar de tenerlo como una acción de guardado.
Podría comentar las declaraciones de importación no utilizadas y las advertencias no le molestarán, pero puede ver lo que tenía.
Una sería que si elimina la clase a la que hace referencia la importación desde el classpath, no obtendrá un error de compilación tonto que no sirvió para nada. Y no obtendrá falsos positivos cuando realice una búsqueda "donde se usa".
Otro (pero esto sería de naturaleza muy específica) sería si la importación no utilizada tuviera conflictos de nombres con otra importación, lo que provocaría que utilizara nombres totalmente calificados innecesariamente.
Adición: Hoy el servidor de compilación comenzó a fallar en la compilación (ni siquiera en la ejecución de prueba) con un error de falta de memoria. Funcionó bien para siempre y los registros no tuvieron ningún cambio en el proceso de compilación o adiciones significativas que podrían explicar esto. Después de intentar aumentar la configuración de la memoria (¡esto está ejecutando una JVM de 64 bits en un CentOS de 64 bits!) A algo mucho más allá de donde los clientes podían compilar, examiné los registros uno por uno.
Hubo una importación incorrecta que un desarrollador usó y abandonó (usaron la clase, la importaron automáticamente y luego se dieron cuenta de que era un error). Esa importación no utilizada trajo un nivel completamente separado de la aplicación que, si bien el IDE no está configurado para separarlos, el proceso de compilación sí lo está. Esa única importación se arrastró en tantas clases que el compilador intentó compilar sin tener las bibliotecas dependientes relevantes en el classpath, que esto causó tantos problemas que causó el error de falta de memoria. Tomó una hora resolver este problema causado por una importación no utilizada.