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

Question

Me pregunto si hay alguna razón (además de ordenar el código fuente) por la cual los desarrolladores usan " Eliminar Usos no utilizados " ¿Característica en Visual Studio 2008?

Answer 1

Hay algunas razones por las que desea eliminarlos.

• No tiene sentido. No agregan ningún valor.
• Es confuso. ¿Qué se está utilizando desde ese espacio de nombres?
• Si no lo hace, acumulará gradualmente sin sentido utilizando declaraciones 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 eliminarlos. Pero si eres tan flojo, ¡tienes problemas más grandes!

Answer 2

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

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

Si tiene una enorme lista larga de uso de declaraciones que realmente no son necesarias, mirar el código podría ser bastante confuso. ¿Por qué está usando eso allí, si no se usa nada de ese espacio de nombre?

Supongo que en términos de mantenibilidad a largo plazo en un entorno profesional, sugiero encarecidamente que mantenga su código lo más limpio posible, y eso incluye eliminar cosas innecesarias de él. Menos desorden equivale a menos confusión y, por lo tanto, a una mayor capacidad de mantenimiento.

Marc

Answer 3

Esto me parece una pregunta muy sensata, que la gente que responde es tratada de manera bastante impertinente.

Diría que cualquier cambio en el código fuente debe estar justificado. Estos cambios pueden tener costos ocultos, y la persona que plantea la pregunta quería que lo supieran. No pidieron que se los llamara "perezosos", como una persona inimachada.

Acabo de comenzar a usar Resharper, y está comenzando a dar advertencias y sugerencias de estilo sobre el proyecto del que soy responsable. Entre ellos está la eliminación de la directiva de uso redundante, pero también calificadores redundantes, capitalización y muchos más. Mi instinto es ordenar el código y resolver todas las sugerencias, pero mi jefe de negocios me advierte contra cambios injustificados.

Utilizamos 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 automáticos que no entregan cambios funcionales a 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 la capitalización de los anacronismos (es decir, ABCD - > Abcd), entonces tengo que tener en cuenta que Resharper no refactoriza ninguno de los archivos Xml que utilizamos con los nombres de clase de referencia.

Entonces, seguir estos consejos no es tan sencillo como parece, y debe tratarse con respeto.

Answer 4

Menos opciones en la ventana emergente 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.

Answer 5

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 una clase llamada Path. Podríamos solucionarlo utilizando la ruta de clase completa,

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

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

Answer 6

Eliminarlos. Menos código para mirar y preguntarse sobre ahorra tiempo y confusión. Desearía que más personas MANTENAN LAS COSAS SIMPLES, ordenadas y ordenadas. Es como tener camisas y pantalones sucios en tu habitación. Es feo y tienes que preguntarte por qué está allí.

Answer 7

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

Answer 8

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

Answer 9

Al menos en teoría, si se le dio 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, incluso puede crear una herramienta para hacerlo automáticamente. Si usted lo hace, al menos en mente, puede asegurarse de comprender todo lo que dice el archivo de código.

Ahora considere, si le dieron un archivo .cs con 1000 directivas usando que solo 10 fueron usadas. Cada vez que observe 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 descubrir qué es. Obviamente, esto ralentiza el procedimiento anterior. Entonces, si puede reducirlos a 10, ¡será útil!

En mi opinión, la directiva C # using es muy muy débil, ya que no se puede especificar un símbolo genérico único sin que se pierda la genericidad, y no se puede usar la directiva using alias para utilizar métodos de extensión Este no es el caso en otros idiomas como Java, Python y Haskell, en esos idiomas puede especificar (casi) exactamente lo que quiere del mundo exterior. Pero, entonces, sugeriré usar usando alias siempre que sea posible.

Answer 10

Recientemente recibí otra razón por la cual eliminar las importaciones no utilizadas es bastante útil e importante.

Imagine que tiene dos ensamblajes, donde uno hace referencia al otro (por ahora llamemos al primero A y al B referenciado). 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 ya no necesita ese código, pero deja la instrucción de uso donde estaba. Ahora no solo tiene un sin sentido usando -directiva sino también una referencia de ensamblaje a B que no se usa en ninguna parte sino en la directiva obsoleta. En primer lugar, esto aumenta la cantidad de tiempo necesario para compilar A , ya que también debe cargarse B .

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

Finalmente, en nuestro ejemplo, tuvimos que enviar B y A juntos, aunque B no se usa en ninguna parte de A sino en la sección using . Esto afectará masivamente el tiempo de ejecución - rendimiento de A cuando carga el ensamblaje.