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é?.