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

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.

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!

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

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.

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;.

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.

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í.

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.

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

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.

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.