que - Scala: ¿Dónde debo colocar las declaraciones de importación?
guia declaracion de exportacion (5)
Scala permite importar casi lo que quieras, donde quieras, y esto es genial. Pero, ¿hay alguna consideración que deba tener en cuenta al importar algo dentro de la clase, el método o cualquier bloque? ¿Cómo se relaciona con el rendimiento, el estilo, la capacidad de mantenimiento del código, etc.?
Generalmente trato de obedecer estas reglas (hechas por mi mismo):
- Si estoy importando algo externo de otro paquete, siempre lo coloco en la parte superior justo después del "paquete".
- Si uso algo más de una vez en el mismo archivo, también lo importo desde arriba.
- De lo contrario, coloco mis importaciones en la parte superior de la clase / rasgo / objeto relevante.
- Evito importar cosas en métodos y bloques.
- Intento evitar importar contenidos de objetos de instancia, a menos que tenga una buena razón para hacerlo.
- Evitaría cambiar el nombre y "ocultarlo" a menos que resuelva las colisiones de nombres, pero nunca lo he necesitado.
¿Esas "reglas" tienen sentido para ti? ¿Me estoy restringiendo demasiado?
Las pautas de importación en Scala eficaz dicen:
Poner las importaciones en la parte superior del archivo.
El lector puede referirse a todas las importaciones en un solo lugar.
En algunas bases de código con las que he trabajado, había una tendencia a importar lo mismo varias veces en varios lugares en el mismo archivo, porque el desarrollador no lo comprobó. Sería bueno si los IDE pudieran promover automáticamente las importaciones a nivel de bloque si detectan múltiples instancias de ellos, pero AFAIK el que yo uso (IntelliJ) no hace esto.
Cuando se trabaja en archivos grandes, muchas personas tienden a mirar solo su código local, por lo que pueden importar localmente algo que entra en conflicto con otras partes del paquete (por ejemplo, en una clase, la Promise se importa desde scala.concurrent y en otra desde akka.dispatch ), y es más difícil de detectar esto cuando se tienen rociadas de importaciones por todas partes.
Esto puede o no ser relevante para su base de código particular, pero personalmente tiendo a ser pesimista sobre el código que mantengo (entropía y todo eso) y, por lo tanto, trato de establecer reglas desde el principio que aseguren el mantenimiento a largo plazo.
Editar: eliminó una referencia a la regla BlockImportChecker de ScalaStyle , que no está relacionada.
No.
Evito importar cosas en métodos y bloques.
¿Por qué?
Si sientes una diferencia, tiene que haber una diferencia objetiva, porque los sentimientos son eventos objetivos y no se originan en la nada.
Se pueden medir, no fácilmente y con precisión con nuestros instrumentos actuales, y tal vez no pueda establecer conexiones con otros hechos objetivos, que expliquen estos sentimientos.
Para mí, parece que usted se adhiere a un tipo de regla de orden, "las importaciones pertenecen a la parte superior", que puede provenir de un idioma que aprendió antes, donde hay una necesidad objetiva de colocarlas en la parte superior. Sin la necesidad, puede ordenarlos cerca de la primera dependencia, eliminarlos fácilmente, si elimina el código dependiente y facilita al lector, averiguar por qué existe la importación y de dónde proviene una clase o rasgo. es importado, por ejemplo colecciones.mutable podría ser una importación de este tipo.
Por lo general, tiene sentido restringir el alcance de algo (por ejemplo, una variable o un método) al "menos" posible. Por ejemplo, use una definición interna en lugar de una en el nivel de clase. ¿Por qué las declaraciones de importación deberían ser diferentes? ¿Por qué contaminar una clase con importaciones que solo se usan en un solo bloque?
¡Me gusta declarar las importaciones lo más cerca posible de donde se usan!
El resultado de esto es que las utilidades comunes, tanto las bibliotecas como scalaz y la mía, tienden a importarse una vez en el nivel superior (porque se usan en toda la clase). Mientras que cosas como I / O se importan localmente, solo donde se usan
Ponga las importaciones en la parte superior de un archivo.
Tenerlos dispersos por todo un archivo hace que sea más difícil leer el código:
- No transmiten un significado lógico, son simplemente un alias; así, "contaminan" el código que refleja el aspecto lógico del programa.
- No se puede esperar dónde encontrarlos (para eso son las convenciones).
- En archivos con múltiples referencias a entidades con el mismo nombre pero con un espacio de nombres diferente, es difícil hacer un seguimiento de lo que ese nombre hace referencia en todos los ámbitos.
No veo ningún beneficio en colocarlos al lado de su alcance más cercano. En realidad, con este razonamiento en mente, uno nunca debería usarlos; en su lugar, siempre se debe usar el espacio de nombres completo para cada entidad referenciada. ¿Eso tiene algún sentido? En mi humilde opinión, no.
Debe recordar que Scala todavía es un lenguaje compilado, y todas las reglas aplicables a Java como un lenguaje de compilación también son aplicables a un Scala. El compilador debe saber a qué símbolo se refiere cuando dice List o Function .
Puede usar instrucciones de importación en bloque pero usarlas con cuidado. El uso excesivo puede llevar a una comprensión inconsistente de los archivos de origen por parte de otras personas. Sería un inconveniente si el límite de una sola clase usara dos definiciones diferentes de List dependiente del contexto.