Declaración de los using ¿dentro o fuera del namespace?
.gif)
Introducción
Programas tanto y vas tan deprisa, que a veces no caes en algunos conceptos, otras veces simplemente te olvidas de ellos, y en otras ocasiones, has hecho las cosas porque sí casi sin pararte a pensar en el porqué.
Funcionar funcionan sí, pero no siempre es así.
El problema
Recientemente en un proyecto con C# me he encontrado (una vez más) con la tesitura de decidir en qué sitio deben ir los using.
¿Dentro o fuera del namespace?.
Normalmente los he puesto siempre dentro, y el caso es que si no lo hago y ejecuto StyleCop, éste me empieza a brear con avisos sobre la idoneidad de poner los using dentro del namespace.
Bien, vale, aceptamos pulpo como animal de compañía y salimos del paso, pasamos el análisis de código y continuamos, pero… ¿qué implicaciones o qué más da ponerlo dentro o fuera?.
Lo mejor es verlo con un sencillísimo ejemplo que nos demuestre que ponerlo dentro o ponerlo fuera NO DA IGUAL.
Y ojo, que cuando digo que NO DA IGUAL, quiero decir literalmente,… CUIDADO, PORQUE LA PODEMOS CAGAR.
La explicación
Partimos de una clase:
namespace UsingInsideOutside { public class Math { public static double PI = 6.28F; } // Math } // UsingInsideOutside
La clase se explica por sí sola… una variable estática y pública con un valor de PI que me he inventado para demostrar las implicaciones del uso de using dentro o fuera del namespace.
Ahora la otra clase con el using fuera del namespace y objeto de la primera prueba demostrativa:
using System; namespace UsingInsideOutside.Other { public class Foo { public static double Calculate(double value) { return Math.PI * value; } // Calculate } // Foo } // UsingInsideOutside.Other
Y ahora el código de ejecución de este ejemplo:
MessageBox.Show(UsingInsideOutside.Other.Foo.Calculate(1).ToString());
¿Qué resultado obtendremos?
6.28…
¿Y si ponemos el using dentro?:
namespace UsingInsideOutside.Other { using System; public class Foo { public static double Calculate(double value) { return Math.PI * value; } // Calculate } // Foo } // UsingInsideOutside.Other
Si ejecutamos nuevamente nuestro código de ejemplo, ¿qué resultado obtendré?.
3.14…
Entonces… está claro que hay implicaciones directas entre poner el using dentro o fuera del namespace,… pero ¿porqué?.
La explicación es muy simple.
Al poner el using dentro del namespace, el compilador busca PI dentro de los using, encontrándolo en using System;.
Si no lo encuentrara, lo buscaría en UsingInsideOutside.
Para demostrar esto último, simplemente debemos renombrar using System; por otro namespace como using System.Collections;, o eliminar o comentar using System; y observar que el valor que devuelve es 6.28…
En el caso de poner el using fuera del namespace, el compilador busca los using, y como no encuentra ninguno, pasa a buscarlo en UsingInsideOutside.
Allí encuentra a PI y es el que utiliza.
Ahora bien, ¿qué ocurre si ponemos los dos namespaces (using System; y using UsingInsideOutside;) dentro del namespace?.
En este caso, el compilador dará un error de ambigüedad, ya que no sabrá si debe hacer referencia a PI de System o a PI de UsingInsideOutside.
Como podemos ver, la cosa se complica poco a poco.
Así que vamos con otro paso… ¿qué pasa entonces si ponemos las dos referencias (using System; y using UsingInsideOutside;) fuera del namespace?.
El compilador no dará errores, es más… la aplicación se ejecutará correctamente.
¿Qué resultado dará entonces?.
6.28…
¿Porqué?.
Simplemente porque estando en UsingInsideOutside.Other, busca los using dentro de su namespace, y como no encuentra ninguno, se pone a buscar los de su propio ensamblado raiz primero (UsingInsideOutside) para buscar posteriormente los de System.
A efectos de simplificar, es exactamente el mismo resultado que utilizar el ejemplo de poner el using System; fuera del namespace sin hacer referencia a UsingInsideOutside.
Así que como podemos observar, el orden de los factores SÍ altera el poducto.
NO es lo mismo poner los using dentro del namespace que fuera.
Por eso, decidir un aspecto como este es muy importante y no es para nada trivial.
¿Y cuales son las implicaciones de todo esto en tiempo de ejecución?
Ahora bien… ¿y como se comporta .NET en tiempo de ejecución?
Aquí viene lo bueno… o mejor dicho, la segunda parte que aporta un valor añadido a lo ya he comentado (por si no era interesante por sí solo).
La pregunta sería: ¿qué implicaciones existen en .NET en tiempo de ejecución y por lo tanto en rendimiento en usar los using dentro o fuera de un namespace?.
Según leí un día de acuerdo a una recomendación (creo recordar que del equipo de StyleCop), si ponemos los using dentro del namespace, .NET cargará el ensamblado referenciado sólo cuando éste es llamado. Es decir, cuando la clase que lo utiliza se carga y se lanza.
Por contra, si ponemos los using fuera del namespace, .NET cargará el ensamblado o ensamblados al cargar el ensamblado principal (el ejemplo entero que hemos preparado para ser más concretos).
¿Y esto afectaría al rendimiento?. Si es así, evidentemente sí, y no sólo al rendimiento, sino también al consumo de memoria de un ensamblado.
El problema no obstante es que yo no he logrado realizar ejemplos que demuestren esto, así que lo voy a dejar como conjetura. De hecho, las pruebas que he hecho no desvelan apenas variaciones. Es más, el IL es casi idéntico.
Cierto es que es un ejemplo tan sencillo que no se aprecia diferencias entre una forma y otra.
No obstante, he ejecutado una instrucción para saber qué ensamblados cargaba el ejemplo con using dentro y fuera del namespace y en ambos casos son los mismos, así que casi podríamos decir que la afirmación anterior es un «mito».
Intentaré sacar más conclusiones al respecto de esto último, de hecho lo dejo por aquí por si alguien se ha topado con este asunto o no y quiere compartir sus experiencias, pero creo firmemente que no hay relación entre declarar los using dentro o fuera de un namespace y la carga y rendimiento de la aplicación.
Conclusiones
Después de todo esto y pese a la última parte de la entrada (la del «mito»), es que la recomendación de StyleCop tiene su sentido, y yo por lo menos es la que voy a seguir usando, eso sí, teniendo en cuenta estos detalles que a veces pasan desapercibidos y que a lo mejor nunca te habías cuestionado. Que sirva esta entrada para que no pensemos haber visto fantasmas en nuestro código.
Espero que os haya parecido interesante lo tratado en esta entrada.
Compártelo
¿Qué piensas tú o cómo lo haces en tus proyectos y porqué?.
5 Responsesso far
Gracias Jorge, a mi y a la gente que trabaja conmigo nos acabas de responder a una discusión que tenemos desde hace tiempo con el tema de los using.
Yo pensaba que no tenía ninguna implicación el ponerlos fuera o dentro del namespace, lo que sí me habían comentado es que las métricas de código penalizaban los using fuera.
Un saludo.
Muchas gracias, yo siempre los ponía fuera por comodidad y mira por donde es mejor dentro.
Hola Jorge,
Muy interesante el post y muy clara la explicación.
Sobre la «conjetura» de la segunda parte, Scott Hanselman tiene un post con algunas pruebas sobre el mismo tema y concluye lo mismo que comentas aquí. Los usings dentro o fuera del namespace impactan directamente en la resolución de los tipos, pero no en la carga de los ensamblados en memoria.
La url: http://www.hanselman.com/blog/BackToBasicsDoNamespaceUsingDirectivesAffectAssemblyLoading.aspx
Al final hay un enlace a un post siilar de Ian Griffiths con resultados similares.
Un saludo
Hola Jorge, siento decirte que da igual como uses los namespaces en tiempo de ejecución. Me explico. Nosotros estamos usando C#, que es un lenguaje de alto nivel. Ese código fuente se compila de C# a IL, que es el lenguaje intermedio de .NET, así para saber realmente en que afecta el rendimiento tenemos que verlo en IL, no en C#. Ahora bien, en IL no existen los namespaces. No existen de ninguna forma. Los nombres de las clases son justamente todo, no el namespace solo y en nombre de la clase, sino todo el string, así cuando nos referimos a la clase Button, no es Button, sino, System.Windows.Controls.Button. Eso se puede ver bien en IL porque cuando se instancia una clase siempre se usa el FQCN (Full Qualified Class Name).
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] string ‘value’,
[1] float64 CS$0$0000)
L_0000: nop
L_0001: ldc.r8 1
L_000a: call float64 UsingInsideOutside.Other.Foo::Calculate(float64)
L_000f: stloc.1
L_0010: ldloca.s CS$0$0000
L_0012: call instance string [mscorlib]System.Double::ToString()
L_0017: stloc.0
L_0018: ldloc.0
L_0019: call void [mscorlib]System.Console::WriteLine(string)
L_001e: nop
L_001f: ret
}
Ahora el problema que tienes con los using dentro o fuera es la prioridad. Teniendo en cuenta lo de antes, cuando nosotros usamos Math, debería de ser System.Math, pero el compilador por comodidad concatena la directiva using con el nombre la clase, así que cuando los using están fuera, tus clases tienen prioridad, cuando están dentro las clases del framework. Y en el caso concreto de Math.PI, es una constante, y las constantes no se referencias se copia el valor de la constante en el ensamblado que lo consume y se elimina la referencia, por eso hay que tener en cuenta el problema que conlleva usar constantes en tu aplicación.
Saludos. Luis.
@Laser, @Juan, muchas gracias por vuestros comentarios. 🙂
@Hugo, muchas gracias por los enlaces. La verdad es que clarifica lo que sospechaba, que aunque tenga su lógica, conviene demostrar.
@Luis, efectivamente es como dices, hay que ver el IL y no el código de C#, de hecho es lo primero que hice y de ahí saqué la conclusión de que no afecta al rendimiento, algo que Hugo me ha aclarado con su enlace y tú me has confirmado.
Sobre las constantes, tienes razón, el valor de una constante es copiado, pero el ejemplo es igualmente clarificador.
De todos los modos, y por agregar otra demostración que no se base en el uso de constantes y para despejar posibles dudas al leer tu último comentario de las constantes (creo que alguno le podría hacer pensar que el orden de los using sólo afecta al uso de constantes), aquí dejo otro pequeño ejemplo pero esta vez con un método estático y cuyo resultado es exactamente el mismo que exponía:
namespace UsingInsideOutside
{
public class Math
{
public static byte Max(byte value1, byte value2)
{
return (byte)(value1 + value2);
}
} // Math
} // UsingInsideOutside
————————————————————
using System;
namespace UsingInsideOutside.Other
{
public class Foo
{
public static byte Calculate(byte value1, byte value2)
{
return Math.Max(value1, value2);
} // Calculate
} // Foo
} // UsingInsideOutside.Other
————————————————————
namespace UsingInsideOutside.Other
{
using System;
public class Foo
{
public static byte Calculate(byte value1, byte value2)
{
return Math.Max(value1, value2);
} // Calculate
} // Foo
} // UsingInsideOutside.Other
A la función Calculate le paso los valores 1 y 2, y en un caso me devuelve 3 y en el otro 2.
Un saludo y muchas gracias a todos por vuestros comentarios, se agradecen mucho estas aportaciones. 🙂