Saltar al contenido

¿Alguna razón para limpiar las importaciones no utilizadas en Java, además de reducir el desorden?

Solución:

No creo que haya problemas de rendimiento o algo por el estilo si no elimina 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 atajo (depende del 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 nuevamente, eclipse la agregará automáticamente mientras completa la declaración con Ctrl + SPACE. Por lo tanto, no es necesario 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 leen el código y dejar algo en su código activo porque tal vez lo necesite más tarde se considera una mala práctica.

Una sería que si elimina la clase a la que hace referencia la importación de la ruta de clase, no obtendrá un error tonto del compilador que no sirvió para nada. Y no obtendrá falsos positivos cuando realice una búsqueda “dónde se usa”.

Otro (pero esto sería de naturaleza muy específica) sería si la importación no utilizada tuviera conflictos de nomenclatura con otra importación, lo que le haría usar nombres completamente calificados innecesariamente.

Anexo: Hoy, el servidor de compilación comenzó a fallar en la compilación (ni siquiera la ejecución de prueba) con un error de memoria insuficiente. Funcionó bien para siempre y los registros no tuvieron ningún cambio en el proceso de compilación o adiciones significativas que pudieran explicar esto. Después de intentar aumentar la configuración de la memoria (¡esto es ejecutar una JVM de 64 bits en un CentOS de 64 bits!) A algo mucho más allá de donde los clientes podrían compilar, examiné los registros uno por uno.

Hubo una importación incorrecta que un desarrollador había usado y abandonado (usaron la clase, la importaron automáticamente y luego se dieron cuenta de que era un error). Esa importación no utilizada extrajo 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 es. Esa única importación arrastró tantas clases que el compilador intentó compilar sin tener las bibliotecas dependientes relevantes en la ruta de clases, que esto causó tantos problemas que causó el error de falta de memoria. Se tardó una hora en resolver este problema causado por una importación no utilizada.

Desde un punto de vista purista, cualquier dependencia es una “restricción” del producto y, por lo tanto, puede causar problemas de mantenimiento en el futuro.

Por ejemplo, supongamos que su programa usa la clase com.XYZObjectPool, y que luego decide no usarla pero nunca eliminar la importación. Si alguien más ahora quiere crear una instancia de org.WVYObjectPool y simplemente hacer referencia a ObjectPool, no recibe ninguna advertencia al respecto hasta que en algún lugar de la línea haya un problema de conversión o de invocación.

Por cierto, este no es un escenario poco realista. Cada vez que Eclipse le preguntaba qué versión específica de X deseaba importar, y eligió uno de entre muchos paquetes, es un escenario en el que si ha tenido la importación allí, es posible que haya obtenido la elección incorrecta sin saberlo.

De cualquier manera, puede pedirle a Eclipse que los limpie por usted

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *