¿Debo aceptar prohibir la directiva de "uso" de mis proyectos de C#?

Question

Mi colega insiste en especificar explícitamente el espacio de nombres en el código en lugar de usar el using directive. En otras palabras, quiere usar el nombre completo para cada tipo cada vez que este tipo aparece en el código. Algo así como

public class MyClass 
{ 
    public static void Main() 
    { 
     System.Console.WriteLine("Foo"); 
    } 
} 

en lugar de:

using System; 
public class MyClass 
{ 
    public static void Main() 
    { 
     Console.WriteLine("Foo"); 
    } 
} 

Se puede imaginar las consecuencias.

Las ventajas que ofrece:

1. Es más fácil de copiar y pegar el código en otros archivos de origen.
2. Es más legible (ve los espacios de nombres de inmediato).

Mis contras:

1. que tienen que escribir más
2. El código es menos legible (supongo de gustibus non disputandum est)
3. Nadie lo hace!

¿Qué opina sobre esto?

Answer 1

Para una respuesta ligeramente diferente: LINQ.

Los métodos de extensión se obtienen solo mediante declaraciones "using". Por lo tanto, la sintaxis de la consulta o la interfaz fluida serán solo que funcionan con las instrucciones correctas "using".

Incluso sin LINQ, yo diría usar "usar" ... razonando que mientras más puedas entender en menos caracteres, mejor. Algunos espacios de nombres son muy profundos, pero no agregan ningún valor a su código.

También existen otros métodos de extensión (no solo LINQ) que sufrirían lo mismo; claro, puedes usar la clase estática, pero la interfaz fluida es más expresiva.

Answer 2

Si necesita copiar y pegar el código tanto como para beneficiarse de tener tipos completamente calificados, tiene problemas mayores.

Además, ¿tiene pensado recordar en qué espacio de nombres está cada clase para poder escribirla como totalmente calificado?

Answer 3

El Law of Demeter dice que se debe utilizar único punto:

Para muchos modernos lenguajes orientados a objetos que utilizan un punto como identificador de campo, la ley puede afirmar simplemente como "usar sólo un punto". Es decir, el código "a.b.Método()" infringe la ley donde "a.Método()" no.

Por supuesto, esto no siempre es práctico. Pero largas cadenas de identificadores separados por puntos violan la práctica aceptada.

EDIT: Esta respuesta parece controvertida. Traje el Law of Demeter principalmente como una guía de estilo, y la mayoría de las respuestas aquí parecen coincidir en que es una buena idea limitar el número de puntos. En mi opinión, jQuery (y JavaScript) adolecen de problemas de legibilidad, en parte porque se introducen puntos excesivos en cualquier programa no trivial.

Answer 4

Porque tenemos una herramienta en C# para autoajustar la instrucción de uso, presionando Ctrl + punto - No veo ninguna razón para no usarla.La otra cosa "fresco" aquí, es:

Piense usted tiene dos espacios de nombres:

ConsoleNamespace1

y

ConsoleNamespace2

Ambos tienen una clase de consola. Ahora puede cambiar todas las referencias a ConsoleNamespace2, con solo una línea de código, eso es genial.

Mi consejo: Use using si puede, el completo si es necesario. No creo que sea completamente uno, si es más fácil de leer. Conozca su marco, y esto nunca será un problema.

Answer 5

Oh muchacho. Un paso podría ser enseñarle a tu colega acerca de ctrl +. Se insertará automáticamente usando declaraciones para usted.

Answer 6

Mi regla general es que si voy a utilizar elementos de un espacio de nombres particular más de unas pocas veces, se obtiene una directiva de uso. Sin embargo, no quiero llenar la parte superior del archivo con el uso de directivas para cosas que solo uso una o dos veces.

Answer 7

Hacer que sea más fácil mover el código copia y pegar es simplemente un non sequitur, y posiblemente una señal de advertencia de práctica potencialmente peligrosa. La estructura y legibilidad del código no debe dictarse por la facilidad de edición.

En todo caso, hace que el código sea menos legible y más específico - personalmente no me interesan los objetos estándar, es como dirigirse a su colega por su nombre completo, con la dirección de su lugar de trabajo.

Hay veces, sin embargo, donde ocasionalmente hace que el código sea más legible, por lo que las reglas estrictas y rápidas no son aplicables, solo el sentido común.

Answer 8

Lo recomiendo en contra de la proposición de su colega. Para mí, leer códigos es mucho más fácil si no tienes un espacio de nombre largo que ocupe demasiado la línea. Imagínese esto:

Namespace1.Namespace2.Namespace3.Type var = new Namespace1.Namespace2.Namespace3.Type(par1, par2, par3); 

en contraposición a:

Type var = new Type(par1, par2, par3); 

En cuanto a copiar y pegar - usted tiene Shift + Alt + F10 que añadir el espacio de nombres, por lo que no debería ser un problema.

Answer 9

¿Qué opino de esto?

Creo que una persona que se le ocurra una idea como esta y que la justifique de la forma en que lo hizo es muy probable que tenga otros malentendidos fundamentales sobre el lenguaje C# y el desarrollo de .NET.

Answer 10

También vale la pena señalar que una herramienta como ReSharper (¿por qué no la está usando ya?) Agregará las líneas de "uso" apropiadas para usted prácticamente de manera automática.

Answer 11

Instale ReSharper en sus máquinas. Siéntate y deja que guíe a tu colega hacia la rectitud. En serio, hay batallas más grandes, pero este es el tipo de codificador que se debe evitar si lleva más de dos minutos intentar educar.

Answer 12

Una de las razones por las que utilizas "usar" es que le dice a cualquiera que lea la fuente el tipo de cosas que hará tu clase. El uso de System.IO le dice a un lector que está haciendo operaciones de E/S, por ejemplo.

Answer 13

También puede utilizar alias ...:

using diagAlias = System.Diagnostics; 

namespace ConsoleApplication1 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      diagAlias.Debug.Write(""); 
     } 
    } 
} 

Answer 14

El mayor problema que encuentro con no usar el "uso" directiva no está en instantiantion y definición de clases. Se trata de pasar valores a las funciones definidas definidas en el espacio de nombres. Compara estas dos piezas de código (VB.Net, porque eso es lo que sé, pero entiendes la imagen).

Module Module1 

    Sub Main() 
     Dim Rgx As New System.Text.RegularExpressions.Regex("Pattern", _ 
      System.Text.RegularExpressions.RegexOptions.IgnoreCase _ 
      Or System.Text.RegularExpressions.RegexOptions.Singleline _ 
      Or System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace) 


     For Each result As System.Text.RegularExpressions.Match In Rgx.Matches("Find pattern here.") 
      'Do Something 
     Next 
    End Sub 

End Module 

Y esto

Imports System.Text.RegularExpressions 

Module Module1 

    Sub Main() 
     Dim Rgx As New Regex("Pattern", _ 
      RegexOptions.IgnoreCase _ 
      Or RegexOptions.Singleline _ 
      Or RegexOptions.IgnorePatternWhitespace) 


     For Each result As Match In Rgx.Matches("Find pattern here.") 
      'Do Something 
     Next 
    End Sub 

End Module 

En casos como este, donde se utilizan una gran cantidad de enumeraciones, así como declarar las variables en línea en un bucle, para reducir su alcance, no usar el "uso" o " importaciones "en el caso de vb.Net, puede llevar a una legibilidad realmente mala.

Answer 15

¿Realmente desea mantener el código de esa manera? Incluso con intellisense, toda esa tipificación no va a ser productiva.

Answer 16

En lugar de 'copiar y pegar', lo llamo 'copiar y pegar' porque el código se usa indebidamente el 99.9% de las veces cuando se somete a este proceso. Entonces, esa es mi respuesta a la justificación # 1 de tu colega para ese enfoque.

En una nota lateral, herramientas como Resharper agregarán las instrucciones de uso en la parte superior cuando agregue código que las necesita a su código (por lo que incluso si 'copia y viola' código así lo puede hacer fácilmente)

Dejando a un lado las preferencias personales, creo que sus justificaciones son mucho más valiosas que las suyas, por lo que incluso suponiendo que sean todos puntos válidos, aún recomendaría escribir las declaraciones de uso en la parte superior. Sin embargo, no lo convertiría en una 'prohibición', ya que veo el estándar de codificación como pautas en lugar de reglas. Dependiendo del tamaño de su equipo, puede ser muy difícil aplicar cosas como esa (o cuántos espacios para sangría, o estilos de sangría, etc., etc.).

Establezca una pauta para que todos los demás desarrolladores se sientan en libertad de volver a asignar los nombres completos con las versiones más cortas y, con el tiempo, la base de códigos se alineará con la guía. Esté atento a que las personas que se toman el tiempo de hacer el trabajo simplemente cambien todas las ocurrencias de un estilo a otro, porque eso no es muy productivo si no está haciendo otra cosa.

Answer 17

En el momento en que su colega dijo "copie y pegue código", perdió toda credibilidad.

Answer 18

Creo que con las características IntelliSense en Visual Studio y el uso de algunos productos de terceros como ReSharper, ya no nos importa hacer que nuestro código sea totalmente calificado o no. Ya no requiere mucho tiempo resolver los espacios de nombres cuando copia y pega su código.

Answer 19

Él podría tener un punto con algunas cosas. Por ejemplo, en una empresa en la que trabajo, tenemos muchas clases generadas por código y, por lo tanto, todas nuestras clases generadas por código utilizamos los nombres completos de las clases para evitar posibles conflictos.

Con todas las clases estándar de .NET que tenemos, solo usamos las instrucciones de uso.

Answer 20

En un sistema como .NET, donde hay tipos de espacios de nombres, debe tomar una decisión: ¿es un espacio de nombres parte del nombre, o es una herramienta de organización para los tipos?

Algunos sistemas eligen la primera opción. Entonces, sus directivas using podrían acortar los nombres que usa con más frecuencia.

En .NET, es el último. Por ejemplo, considere System.Xml.Serialization.XmlSerializationReader. Observe la duplicación entre el espacio de nombres y el tipo. Esto se debe a que en este modelo, los nombres de tipo deben ser únicos, incluso entre espacios de nombres.

Si no recuerdo mal, se puede encontrar esta descrito por el equipo de CLR aquí: http://blogs.msdn.com/kcwalina/archive/2007/06/01/FDGLecture.aspx

Su más fácil de copiar y pegar el código en otros archivos de origen.

Cierto, pero si está copiando/pegando una gran cantidad de código, probablemente lo esté haciendo mal.

Es más fácil de leer (se ven los espacios de nombres enseguida)

Al ver los espacios de nombres no es importante, ya que, al menos cuando se está siguiendo las directrices de Microsoft, nombres de tipos son únicos ya; el espacio de nombres realmente no le proporciona información útil.

Answer 21

Soy alguien que tiene una tendencia a calificar completamente espacios de nombres. Lo hago cuando uso componentes que no conozco/no he usado durante mucho tiempo. Me ayuda a recordar lo que hay en ese espacio de nombres, así que la próxima vez lo busco/clases relacionadas.

También me ayuda a saber si ya tengo las referencias adecuadas en el proyecto. Al igual que si escribo System.Web.UI pero no puedo encontrar Extensions, entonces sé que olvidé/quien configuró el proyecto olvidé poner las referencias ASP.NET AJAX.

Lo estoy haciendo cada vez menos a medida que uso el atajo para calificar una clase (Ctrl +.). Si escribe el nombre de la clase (encajonado correctamente) y presiona ese atajo, puede fácilmente cualificar/agregar fácilmente una declaración de uso.

Es genial para StringBuilder, nunca tengo System.Text, así que simplemente escribo StringBuilder -> Ctrl +. y ahí vamos, agregué el uso.

Answer 22

"En el momento en que su colega dijo" copie y pegue código ", perdió toda la credibilidad". ídem.

"La ley de Demeter dice ..."ditto

... y agrego. Eso es absurdo, no usar declaraciones de uso. Obtenga ReSharper, encuentre la manera de enseñarle a este individuo cómo se hace, y si no parece surtir efecto, con los motivos Dado que es el momento de empezar a buscar otro trabajo, basta con las correlaciones de lo que concuerda con nociones tales como no usar declaraciones. Te quedarás atrapado trabajando 16 horas preparando un desastre si esa es una de las reglas. sin contar qué otro tipo de afrenta al sentido común y la lógica que enfrentará a continuación.

En serio, esto ni siquiera debería plantearse con herramientas como ReSharper disponible. Se está desperdiciando dinero, compre ReSharper, haga limpieza de código , y volver a hacer software utilizable. :) Ese es mi 2 centavos.

Answer 23

si está copiando y pegando código repetidamente, ¿no apunta eso a crear una DLL estándar para incluir en cada uno de sus proyectos?

He trabajado en proyectos usando ambos métodos antes y tengo que decir que tener las instrucciones "Using" tiene sentido para mí, reduce el código, lo hace más legible y tu compilador finalmente optimizará el código en el manera correcta. La única vez que puede tener un problema es si tiene dos clases de dos espacios de nombres que tienen el mismo nombre, entonces tendría que usar el nombre completo ... pero esa es la excepción en lugar de la regla.

Answer 24

¿No es el hecho de que Visual Studio incluye muchas instrucciones de uso en la parte superior de casi todos los archivos que crea una pista de que las declaraciones using se consideran buenas prácticas?

Answer 25

He estado codificando durante 25 años. LOS USOS son esenciales y siempre deben utilizarse, y es una buena práctica de codificación. SIN EMBARGO cualquier buen desarrollador debería tener un repositorio de código. Compartir fragmentos de código es mucho más fácil cuando se incluyen espacios de nombres totalmente calificados.

El comentario COPY & PASTE es una mala técnica por lo general proviene de la boca de aquellos desarrolladores que no se tomaron el tiempo para construir un sólido repositorio de código y no se detuvieron para comprender realmente el código genérico que se probó. Los espacios de nombres totalmente calificados los veo como una necesidad en los repositorios de código o, si no, su búsqueda intenta determinar de dónde proviene el espacio de nombres.