¿Por qué eliminar las directivas using no utilizadas en C #?

120

Me pregunto si hay alguna razón (además de ordenar el código fuente) por las que los desarrolladores usan la función "Eliminar sin usar Usings" en Visual Studio 2008.

bounav
fuente
Creo que es una característica de PowerCommands para Visual Studio, no de Visual Studio en sí.
Hosam Aly
3
En VS2008 es sin duda una característica (junto con la capacidad de ordenar las declaraciones de uso) de VS en sí.
Richard
1
@Hosam: PowerCommands le permite hacer eso para todo el proyecto / solución. Hacer eso por archivo es una característica de VS en sí.
configurador
3
Por cierto, consulte Resharper si desea un control más preciso sobre este tipo de limpieza.
John Feminella
2
De hecho, realmente no me gusta esta función: invariablemente me encuentro editando un archivo y teniendo que volver a agregar todos los espacios de nombres del sistema después de que alguien los haya limpiado (generalmente System, System.Collections.Generic y System.Linq.) Encuentro que agrega más fricción de la que ahorra. Ahora, los espacios de nombres de sus propios proyectos en lugar de los espacios de nombres de marcos, tienen más sentido limpiarlos, para aclarar el cableado de su programa. Ojalá hubiera una manera de que VS limpie las importaciones solo de ciertos espacios de nombres y deje las del Sistema que necesita con más frecuencia.
user1454265

Respuestas:

186

Hay algunas razones por las que querría eliminarlos.

  • Carece de sentido. No añaden valor.
  • Es confuso. ¿Qué se está utilizando de ese espacio de nombres?
  • Si no lo hace, gradualmente acumulará usingdeclaraciones sin sentido a medida que su código cambie con el tiempo.
  • El análisis estático es más lento.
  • La compilación de código es más lenta.

Por otro lado, no hay muchas razones para dejarlos. Supongo que te ahorras el esfuerzo de tener que borrarlos. Pero si eres tan vago, ¡tienes problemas mayores!

John Feminella
fuente
59
Un buen programador ES vago, maximiza el trabajo que NO debe hacer. : D
Nicolas Dorier
34
No estoy de acuerdo con que un buen programador sea vago, pero estoy de acuerdo con el sentimiento de su declaración. Un buen programador los eliminará para mantener limpio su código y así evitar futuros trabajos / problemas / problemas para él y los demás.
Allan
2
Bien, ese es un gran vínculo. Supongo que lo que quiero decir es que queremos "buenos vagos" en lugar de "malos vagos"; este último es donde los programadores no se molestan en escribir un buen código.
Allan
5
También hay mérito en dejar espacios de nombres estándar. En proyectos y equipos grandes, dejarlos en los resultados en menos conflictos potenciales de fusión y menos archivos para revisión de código. Además, muchos desarrolladores agregan métodos de extensión confusos y difíciles de encontrar a las cosas y, a veces, ubicar los espacios de nombres requeridos para estos métodos de extensión es una molestia. Los nuevos desarrolladores pueden estar acostumbrados a tener System.Linq incluido en sus archivos de código y perder mucho tiempo tratando de averiguar por qué ciertos métodos no están disponibles antes de pedir ayuda.
Mark At Ramp51
5
Es posible que desee conservar algunos de ellos para evitar que el intellisense sea tonto como el infierno en la codificación futura.
yazanpro
24

Yo diría todo lo contrario: es extremadamente útil eliminar declaraciones de uso innecesarias e innecesarias.

Imagine que tiene que volver a su código en 3, 6, 9 meses, o alguien más tiene que hacerse cargo de su código y mantenerlo.

Si tiene una larga lista de declaraciones de uso que no son realmente necesarias, mirar el código puede resultar bastante confuso. ¿Por qué se usa eso allí, si no se usa nada de ese espacio de nombres?

Supongo que en términos de capacidad de mantenimiento a largo plazo en un entorno profesional, sugeriría encarecidamente mantener su código lo más limpio posible, y eso incluye deshacerse de cosas innecesarias. Menos desorden equivale a menos confusión y, por lo tanto, mayor facilidad de mantenimiento.

Bagazo

marc_s
fuente
14

Me parece que esta es una pregunta muy sensata, que la gente que responde está tratando de manera bastante frívola.

Yo diría que cualquier cambio en el código fuente debe estar justificado. Estos cambios pueden tener costos ocultos y la persona que planteó la pregunta quiso ser consciente de esto. No pidieron ser llamados "vagos", como una persona insinuó.

Acabo de comenzar a usar Resharper y está comenzando a dar advertencias y sugerencias de estilo en el proyecto del que soy responsable. Entre ellos se encuentra la eliminación de directivas de uso redundantes, pero también calificadores redundantes, uso de mayúsculas y muchos más. Mi instinto es poner en orden el código y resolver todos los indicios, pero mi jefe comercial me advierte sobre cambios injustificados.

Usamos un proceso de compilación automatizado y, por lo tanto, cualquier cambio en nuestro repositorio SVN generaría cambios que no podríamos vincular a proyectos / errores / problemas y desencadenaría compilaciones y lanzamientos automatizados que no produjeron cambios funcionales en las versiones anteriores.

Si observamos la eliminación de calificadores redundantes, esto podría causar confusión a los desarrolladores, ya que las clases de nuestras capas de dominio y datos solo se diferencian por los calificadores.

Si miro el uso adecuado de las mayúsculas de los anacrónicos (es decir, ABCD -> Abcd), entonces tengo que tener en cuenta que Resharper no refactoriza ninguno de los archivos Xml que usamos con los nombres de clase de referencia.

Por lo tanto, seguir estas sugerencias no es tan sencillo como parece y debe tratarse con respeto.


fuente
6
Buen punto, pero tampoco debe olvidar que mantener un código limpio y sin complicaciones mejora la capacidad de mantenimiento, que también es un objetivo comercial. Tienes que ponderar ambos. Idealmente, desea hacer este tipo de refactorizaciones justo después de un lanzamiento para que pueda tener una pizarra lo más limpia posible para comenzar una nueva y tener suficiente tiempo para detectar posibles regresiones.
David Reis
14

Además de las razones ya dadas, evita conflictos de nombres innecesarios. Considere este archivo:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

Este código no se compila porque los espacios de nombres System.IO y System.Windows.Shapes contienen cada uno una clase llamada Path. Podríamos solucionarlo utilizando la ruta de clases completa,

        private static string temporaryPath = System.IO.Path.GetTempFileName();

o simplemente podríamos eliminar la línea using System.Windows.Shapes;.

hipehumano
fuente
13

Menos opciones en la ventana emergente de Intellisense (especialmente si los espacios de nombres contienen muchos métodos de extensión).

Teóricamente, Intellisense también debería ser más rápido.

cbp
fuente
1
+1 para intellisense. En realidad, es lento en el inicio (veo regularmente "Creando caché, inténtalo de nuevo más tarde"), por lo que esto podría ser realmente significativo. Compilar el tiempo del que todos hablan ... todavía tengo que ver los números.
Luc
5

Retirarlos. Menos código para mirar y preguntarse ahorra tiempo y confusión. Deseo que más personas MANTENGAN LAS COSAS SIMPLES, LIMPIAS y ORDENADAS. Es como tener camisas y pantalones sucios en tu habitación. Es feo y tienes que preguntarte por qué está ahí.

Tim Duncan
fuente
4

También ayuda a prevenir dependencias circulares falsas, asumiendo que también puede eliminar algunas referencias dll / project de su proyecto después de eliminar los usos no utilizados.

Jeremy C.
fuente
3

El código se compila más rápido.

Cuenta muerta
fuente
5
¿Tienes alguna evidencia que respalde eso?
cjk
14
Oh CK, me pillaste de nuevo. Mentí. La eliminación de texto innecesario en realidad hace que la compilación del código sea más lenta. Piénselo :)
Cuenta muerta
@ck: He verificado que la eliminación de declaraciones using no utilizadas de un proyecto en el trabajo mejoró el tiempo de compilación en una cantidad notable. Por supuesto que sí, menos bytes para leer en el disco duro.
configurador
19
Sería bueno ver algunas estadísticas reales. Si ahorramos unos pocos milisegundos mientras compilamos, la velocidad no es un argumento convincente. Sin embargo, existen otras razones para eliminar las declaraciones using innecesarias.
Greg
3
No se trata de mentir o no. Cualquier persona sensata adivinaría que menos desorden significa más eficiencia. La "evidencia" para respaldarlo es proporcionar valor a su respuesta y respaldar el argumento de que "más rápido" no significa solo unos pocos ms, sino en realidad una experiencia mejorada para compilar su proyecto más rápido.
Matheus Felipe
3

Recientemente, obtuve otra razón por la que eliminar las importaciones no utilizadas es muy útil e importante.

Imagine que tiene dos ensamblados, donde uno hace referencia al otro (por ahora, llamemos al primero Ay al referenciado B). Ahora, cuando tienes un código en A que depende de B, todo está bien. Sin embargo, en alguna etapa de su proceso de desarrollo, se da cuenta de que en realidad ya no necesita ese código, pero deja la instrucción using donde estaba. Ahora no solo tiene una usingdirectiva sin sentido, sino también una referencia de ensamblado a la Bque no se usa en ningún otro lugar que no sea en la directiva obsoleta. En primer lugar, esto aumenta la cantidad de tiempo necesario para la compilación A, ya Bque también debe cargarse.

Por lo tanto, esto no solo es un problema de código más limpio y fácil de leer, sino también de mantener las referencias de ensamblado en el código de producción, donde ni siquiera existen todos esos ensamblados referenciados .

Finalmente, en nuestro ejemplo, tuvimos que enviar B y A juntos, aunque B no se usa en ninguna parte de A sino en la usingsección. Esto afectará enormemente el rendimiento del tiempo de ejecuciónA al cargar el ensamblaje.

ÉlBromBeere
fuente
2

Al menos en teoría, si le dieran un archivo C # .cs (o cualquier archivo de código fuente de un solo programa), debería poder mirar el código y crear un entorno que simule todo lo que necesita. Con alguna técnica de compilación / análisis, puede incluso crear una herramienta para hacerlo automáticamente. Si lo hace al menos en su mente, puede asegurarse de que comprende todo lo que dice el archivo de código.

Ahora considere, si le dieran un archivo .cs con 1000 usingdirectivas de las cuales solo se usaron 10. Siempre que mire un símbolo que se haya introducido recientemente en el código que hace referencia al mundo exterior, tendrá que pasar por esas 1000 líneas para averiguar qué es. Obviamente, esto ralentiza el procedimiento anterior. Entonces, si puede reducirlos a 10, ¡ayudará!

En mi opinión, la usingdirectiva C # es muy, muy débil, ya que no puede especificar un solo símbolo genérico sin que se pierda la genéricaidad, y no puede usar la usingdirectiva alias para usar métodos de extensión. Este no es el caso en otros lenguajes como Java, Python y Haskell, en esos lenguajes puedes especificar (casi) exactamente lo que quieres del mundo exterior. Pero en ese caso, sugeriré usar un usingalias siempre que sea posible.

Motor de tierra
fuente