sintaxis - ¿Por qué eliminar las directivas de uso sin usar en C#?

sintaxis c#

Question

Me pregunto si hay razones (aparte de poner en orden el código fuente) por qué los desarrolladores usan la función "Eliminar Usings no Usings " en Visual Studio 2008.

Answer 1

Además de las razones ya dadas, previene conflictos de nombres innecesarios. Considera 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 arreglarlo usando la ruta de clase completa,

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

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

Answer 2

Al menos en teoría, si le dieron un archivo .cs de C # (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 esto lo hace usted 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 using directivas, de las cuales solo 10 fueron realmente utilizadas. Cada vez que observe un símbolo recién introducido en el código que hace referencia al mundo exterior, tendrá que pasar por esas 1000 líneas para descubrir qué es. Esto obviamente ralentiza el procedimiento anterior. Entonces, si puedes reducirlos a 10, ¡será útil!

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

Answer 3

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 alguien más tiene que hacerse cargo de su código y mantenerlo.

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

Supongo que en términos de mantenibilidad a largo plazo en un entorno profesional, le sugiero que mantenga 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 capacidad de mantenimiento.

Bagazo

Answer 4

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

Answer 5

Eliminarlos. Menos código para mirar y sobre lo que se puede pensar ahorra tiempo y confusión. Ojalá que más personas MANTENGAN LAS COSAS SIMPLES, NEUTAS y TIDY. Es como tener camisas y pantalones sucios en tu habitación. Es feo y tienes que preguntarte por qué está ahí.

Answer 6

Esta me parece una pregunta muy sensata, que las personas que están respondiendo lo están tratando de una manera bastante frívola.

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 quiere que se lo tenga en cuenta. No pidieron que los llamaran "perezosos", como una persona imaginó.

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 redundante, pero también calificadores redundantes, capitalización y muchos más. Mi instinto es ordenar el código y resolver todos los indicios, pero mi jefe de negocios me advierte contra los 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 versiones automatizadas que no proporcionaron ningún cambio funcional en las versiones anteriores.

Si observamos la eliminación de los 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 observo el uso correcto de mayúsculas y minúsculas de los anacronismos (es decir, ABCD -> Abcd), entonces tengo que tener en cuenta que Resharper no refactoriza ninguno de los archivos Xml que utilizamos esos nombres de clase de referencia.

Por lo tanto, seguir estos consejos no es tan directo como parece, y debe tratarse con respeto.

Answer 7

Hay algunas razones por las que te gustaría eliminarlas.

• Carece de sentido. No agregan ningún valor.
• Es confuso. ¿Qué se está usando desde ese espacio de nombres?
• Si no lo hace, acumulará poco sentido el using 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 allí. Supongo que se ahorrará el esfuerzo de tener que eliminarlos. Pero si eres tan perezoso, ¡tienes problemas más grandes!

Answer 8

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

En teoría, Intellisense también debería ser más rápido.

Answer 9

Recientemente obtuve otra razón por la cual eliminar 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 referido B ). Ahora cuando tienes el código en A que depende de B, todo está bien. Sin embargo, en algún momento de su proceso de desarrollo observará que ya no necesita ese código, pero deja la declaración de uso donde estaba. Ahora no solo tiene una directiva de using sin sentido 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 necesaria para compilar A , ya que B también debe cargarse.

Por lo tanto, esto no solo es un problema en un código más limpio y fácil de leer, sino también en el mantenimiento de las referencias de ensamblaje en el código de producción donde no todos los ensamblados a los que se hace referencia existen .

Finalmente en nuestro ejemplo tuvimos que enviar B y A juntos, aunque B no se usa en ningún lugar en A, sino en la sección de using . Esto afectará de forma masiva el rendimiento en tiempo de ejecución de A cuando se carga el conjunto.

Answer 10

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