¿Por qué debería eliminar C # innecesario utilizando directivas?


216

Por ejemplo, rara vez necesito:

using System.Text;

pero siempre está ahí por defecto. Supongo que la aplicación usará más memoria si su código contiene directivas innecesarias . Pero, ¿hay algo más que deba tener en cuenta?

Además, ¿hace alguna diferencia si la misma directiva de uso se usa en un solo archivo frente a la mayoría / todos los archivos?


Editar: Tenga en cuenta que esta pregunta no se trata del concepto no relacionado llamado declaración de uso , diseñado para ayudar a administrar los recursos al garantizar que cuando un objeto se sale del alcance, se llama a su método IDisposable.Dispose . Consulte Usos de "usar" en C # .

Respuestas:


181

No cambiará nada cuando se ejecute su programa. Todo lo que se necesita se carga bajo demanda. Entonces, incluso si tiene esa declaración de uso, a menos que realmente use un tipo en ese espacio de nombres / ensamblado, el ensamblado con el que se correlaciona la declaración no se cargará.

Principalmente, es solo para limpiar por preferencia personal.


@francip: eso es lo que estoy diciendo. el uso no afecta la carga del conjunto, un conjunto no se carga hasta que se haga referencia a un tipo contenido en el conjunto.
Darren Kopp

69
pero puede afectar el tiempo de compilación y la capacidad de respuesta Intellisense / IDE.
Marchy


475

No son algunas de las razones para la eliminación no utilizado usando (s) / espacios de nombres, además de la preferencia de codificación:

  • eliminar las cláusulas no utilizadas en un proyecto puede acelerar la compilación porque el compilador tiene menos espacios de nombres para buscar los tipos de búsqueda que resolver. (esto es especialmente cierto para C # 3.0 debido a los métodos de extensión, donde el compilador debe buscar en todos los espacios de nombres métodos de extensión para encontrar posibles mejores coincidencias, inferencia de tipos genéricos y expresiones lambda que involucren tipos genéricos)
  • potencialmente puede ayudar a evitar la colisión de nombres en futuras compilaciones cuando se agregan nuevos tipos a los espacios de nombres no utilizados que tienen el mismo nombre que algunos tipos en los espacios de nombres utilizados.
  • reducirá el número de elementos en la lista de finalización automática del editor al codificar, lo que posiblemente conduzca a una escritura más rápida (en C # 3.0 esto también puede reducir la lista de métodos de extensión que se muestra)

Lo que no eliminará los espacios de nombres no utilizados :

  • alterar de ninguna manera la salida del compilador.
  • alterar de alguna manera la ejecución del programa compilado (carga más rápida o mejor rendimiento).

El conjunto resultante es el mismo con o sin uso sin usar (s) eliminado (s).


3
Y a medida que modifica los archivos, terminará agregando más y más espacios de nombres al comienzo de los archivos. Entonces, si no elimina los espacios de nombres no utilizados, cuando abre el archivo, todo lo que ve es una lista gigante de espacios de nombres en lugar de una implementación real.
Mert Akcakaya

55
En cuanto a la compilación más rápida: las usingdirectivas no utilizadas en los .csarchivos pueden evitar que elimine algunas referencias de ensamblaje (de otro modo no utilizadas) de su .csprojproyecto. Si tiene una "solución" de muchos proyectos, las referencias innecesarias entre los proyectos obligarán a los proyectos a compilarse en un orden específico cuando, de hecho, son independientes y pueden compilarse en paralelo. Por lo tanto, elimine las usingdirectivas no utilizadas antes de buscar referencias de proyectos no utilizados en una solución de proyectos múltiples.
Jeppe Stig Nielsen

1
Esta es una gran explicación: al final no tiene mucho que ver con el rendimiento, sino con las mejores prácticas. ¡Gracias por la explicación!
GSaunders

39

La limpieza del código es importante.

Uno comienza a tener la sensación de que el código puede estar sin mantenimiento y en el camino del campo de navegación cuando ve usos superfluos. En esencia, cuando veo algunas declaraciones de uso no utilizadas, una pequeña bandera amarilla se enciende en la parte posterior de mi cerebro y me dice que "proceda con precaución". Y leer el código de producción nunca debería darte esa sensación.

Así que limpia tus usos. No seas descuidado Inspira confianza. Haz que tu código sea bonito. Dale a otro desarrollador esa sensación cálida y difusa.


Ahora eso es lo que quería escuchar :-) Estoy acostumbrado a hacer un de Organize Usings -> Remove and Sortvez en cuando. Por cierto, para mí las dos opciones superiores Organize Usingsno tienen sentido. Estoy hablando de VS2013 por cierto.
Sнаđошƒаӽ

30

No hay una construcción IL que corresponda using. Por lo tanto, lausing declaraciones no aumentan la memoria de su aplicación, ya que no se genera ningún código o datos para ella.

Usingse usa en tiempo de compilación solo con el propósito de resolver nombres de tipo cortos a nombres de tipo completamente calificados. Por lo tanto, el único efecto negativo innecesariousing puede tener es ralentizar un poco el tiempo de compilación y tomar un poco más de memoria durante la compilación. Aunque no estaría preocupado por eso.

Por lo tanto, el único efecto negativo real de tener usingdeclaraciones que no necesita es en intellisense, ya que la lista de posibles coincidencias para completar mientras escribe aumenta.


4

Puede tener conflictos de nombres si llama a sus clases como las clases (no utilizadas) en el espacio de nombres. En el caso de System.Text, tendrá un problema si define una clase llamada "Encoder".

De todos modos, esto suele ser un problema menor y detectado por el compilador.


2

Su aplicación no usará más memoria. Es para que el compilador encuentre las clases que usa en los archivos de código. Realmente no duele más allá de no estar limpio.


2

Es preferencia personal principalmente. Los limpio yo mismo (Resharper hace un buen trabajo al decirme cuando no es necesario usar declaraciones).

Se podría decir que podría disminuir el tiempo de compilación, pero con las velocidades de la computadora y el compilador en estos días simplemente no tendría ningún impacto perceptible.


2

Dejar usingdirectivas adicionales está bien. Hay un poco de valor en eliminarlos, pero no mucho. Por ejemplo, hace que mis listas de finalización de IntelliSense sean más cortas y, por lo tanto, más fáciles de navegar.

Los ensamblados compilados no se ven afectados por usingdirectivas extrañas .

A veces los pongo dentro de un #region, y lo dejo colapsado; Esto hace que ver el archivo sea un poco más limpio. OMI, este es uno de los pocos buenos usos de #region.


1
Pueden colapsarse sin una región
abatishchev

1
@abatishchev: Sí, eso es cierto en VS2010.
Jay Bazuzi

"Uno de los pocos usos buenos de #region", ¿quiere decir que usar #regiones malo en la mayoría de los casos?
Steven

Sí, #regiones un código de olor. Dice que está sucediendo demasiado en tu clase.
Jay Bazuzi

2

si desea mantener limpio su código, las usingdeclaraciones no utilizadas deben eliminarse del archivo. los beneficios parecen muy claros cuando trabaja en un equipo colaborativo que necesita comprender su código, piensa que todo su código debe mantenerse, menos código = menos trabajo, los beneficios son a largo plazo.


1

Solo se usan como atajo. Por ejemplo, tendría que escribir: System.Int32 cada vez que no tuviera un sistema que lo utilizara; encima.

Eliminar los no utilizados solo hace que su código se vea más limpio.


1

La declaración de uso simplemente evita que califique los tipos que usa. Personalmente me gusta limpiarlos. Realmente depende de cómo se use una métrica loc.


1

Tener solo los espacios de nombres que realmente usa le permite mantener su código documentado.

Puede encontrar fácilmente qué partes de su código se llaman entre sí mediante cualquier herramienta de búsqueda.

Si tiene espacios de nombres no utilizados, esto no significa nada al ejecutar una búsqueda.

Estoy trabajando en la limpieza de espacios de nombres ahora, porque constantemente me preguntan qué partes de la aplicación están accediendo a los mismos datos de una forma u otra.

Sé qué partes están accediendo a los datos en cada sentido debido a que el acceso a los datos está separado por espacios de nombres, por ejemplo, directamente a través de una base de datos y directamente a través de un servicio web.

No puedo pensar en una forma más simple de hacer todo esto de una vez.

Si solo desea que su código sea un cuadro negro (para los desarrolladores), entonces sí, no importa. Pero si necesita mantenerlo con el tiempo, es una documentación valiosa como todos los demás códigos.


0

La declaración 'using' no afecta el rendimiento, ya que es simplemente una ayuda para calificar los nombres de sus identificadores. Entonces, en lugar de tener que escribir System.IO.Path.Combine (...) , simplemente puede escribir Path.Combine (...) si ha utilizado System.IO .


0

No olvide que el compilador hace mucho trabajo para optimizar todo al construir su proyecto. Usar eso se usa en muchos lugares o 1 no debería hacer algo diferente una vez compilado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.