Jorge Serrano
  • Home

Declaración de los using ¿dentro o fuera del namespace?

  • By jorge
  • Jun-30-2011
  • Sin categoría
  • 5 Comments.

 

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

 

Comments

5 Responsesso far

  1. anonymous dice:
    30 junio, 2011 a las 3:31 pm

    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.

    Responder
  2. anonymous dice:
    30 junio, 2011 a las 4:29 pm

    Muchas gracias, yo siempre los ponía fuera por comodidad y mira por donde es mejor dentro.

    Responder
  3. anonymous dice:
    30 junio, 2011 a las 4:57 pm

    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

    Responder
  4. lguerrero dice:
    30 junio, 2011 a las 5:44 pm

    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.

    Responder
  5. jorge dice:
    1 julio, 2011 a las 8:38 am

    @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. 🙂

    Responder

Deja un comentario Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Jorge Serrano

MVP Reconnect


¡Subscríbete a mi canal!
YouTube

Donaciones
Donation

Entradas recientes

  • Go – Arrays
  • Go – Operators
  • Go – Constants
  • Go – Tipos de Datos
  • Go – Variables
  • Hello Go-rld!
  • Introducción a Go o Golang
  • JSON Patch en ASP.NET Core 5 Web API
  • Null Checking en C#
  • ¿Porqué mi página web por defecto de ASP.NET Core no se vé en mi Azure Web App y me da un 404?

Categorías

  • .NET 5
  • .NET Core
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET Framework 2.0
  • .NET Framework 3.0
  • .NET Framework 3.5
  • .NET Framework 4.0
  • .NET Framework 4.5
  • .NET Framework 4.6
  • .NET Framework 4.7
  • .NET Framework 4.8
  • .NET Standard 2.0
  • .NET Standard 2.1
  • AMQP
  • Android
  • Angular
  • API REST
  • Apple
  • Apple iOS
  • Apple macOs
  • Arquitectura
  • ASP.NET
  • ASP.NET Core
  • ASP.NET Core 3
  • ASP.NET Core 5
  • AWS
  • Azure App Service
  • Azure Application Insights
  • Azure Cosmos DB
  • Azure Database Migration Service
  • Azure Databricks
  • Azure DevOps
  • Azure Event Grid
  • Azure Functions
  • Azure IoT
  • Azure Portal
  • Azure PowerShell
  • Azure Queue Storage
  • Azure SQL
  • Azure Storage
  • Azure Virtual Datacenter
  • Azure WebApps
  • Big Data
  • Bing
  • Blazor
  • Blog
  • Bots
  • C#
  • C# 7.0
  • C# 7.1
  • C# 7.2
  • C# 7.3
  • C# 8.0
  • C# 9.0
  • Channel 9
  • Codeplex
  • Codespaces
  • Containers
  • Debugging
  • DevOps
  • Docker
  • Electron
  • Entity Framework
  • Entity Framework Core
  • Entity Framework Core 3.0
  • Entity Framework Core 5
  • Eventos
  • F#
  • FaaS
  • FeatureFlags
  • FeatureToggles
  • Feeds
  • Fluent Assertions
  • General
  • GIMP
  • Git
  • GitHub
  • Go
  • Google
  • Google Analytics
  • Gradle
  • gRPC
  • GSA
  • Historia de la Informática
  • HoloLens
  • HtmlAgilityPack
  • IdentityServer4
  • Inkscape
  • Ionic
  • iOS
  • IoT
  • Java
  • JavaScript
  • JDBC
  • JSON
  • Kubernetes
  • Lenguajes de Programación
  • Libros y Cursos
  • LINQ
  • Linux
  • LiteDB
  • Machine Learning
  • macOS
  • Microservices
  • Microsoft
  • Microsoft .NET Framework 4.5
  • Microsoft 365
  • Microsoft Azure
  • Microsoft Build
  • Microsoft Ignite
  • Microsoft Learn
  • Microsoft Orleans
  • Microsoft Surface Go
  • Microsoft Teams
  • ML.NET
  • MQTT
  • MRO
  • MS-DOS
  • MsCoders Madrid
  • MVP
  • NancyFx
  • Node.js
  • NoSQL
  • NuGet
  • NUnit
  • OData
  • ODP.NET Core
  • Office 2007
  • Office 2010
  • Office 2013
  • Office 2016
  • Office 2019
  • Office 365
  • Open Source
  • Open XML SDK
  • Opinión
  • Orchard CMS
  • OT
  • PaaS
  • Patterns
  • PdfSharpCore
  • Performance
  • PHP
  • Postman
  • Power BI
  • PowerShell
  • PowerShell Core
  • Productividad
  • Project Server 2019
  • R
  • Rendimiento
  • Scala
  • Scraper
  • Security
  • Serverless
  • Service Fabric
  • SharePoint Server 2019
  • SignalR
  • Sin categoría
  • Sistemas Distribuidos
  • Skype
  • Skype for Business Server 2019
  • Small Basic Online
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2014
  • SQL Server 2016
  • SQL Server 2017
  • SQL Server 2019
  • STOMP
  • Swagger
  • Testing
  • TFS 2017
  • TFS 2018
  • Tools
  • TypeScript
  • Unity
  • UWP
  • UX
  • Visio
  • Visual Basic
  • Visual Studio 2010
  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio 2015
  • Visual Studio 2017
  • Visual Studio 2017 for Mac
  • Visual Studio 2019
  • Visual Studio 2019 for Mac
  • Visual Studio App Center
  • Visual Studio Code
  • Visual Studio IntelliCode
  • Visual Studio Live Share
  • Visual Studio Live Share Audio
  • Visual Studio Online
  • VS Anywhere
  • Vue.js
  • Web API
  • WebAssembly
  • WinDbg
  • Windows
  • Windows 10
  • Windows Compatibility Pack
  • Windows Phone 10
  • Windows Phone 7
  • Windows Phone 8
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Service
  • WinForms
  • WinUI
  • WPF
  • Xamarin
  • Xbox
  • Xcode
  • Xiaomi Mi Band 2
  • xUnit
  • YAML

Archivos

  • enero 2021
  • diciembre 2020
  • noviembre 2020
  • octubre 2020
  • septiembre 2020
  • agosto 2020
  • julio 2020
  • junio 2020
  • mayo 2020
  • abril 2020
  • marzo 2020
  • febrero 2020
  • enero 2020
  • diciembre 2019
  • noviembre 2019
  • octubre 2019
  • septiembre 2019
  • agosto 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • marzo 2019
  • febrero 2019
  • enero 2019
  • diciembre 2018
  • noviembre 2018
  • octubre 2018
  • septiembre 2018
  • agosto 2018
  • julio 2018
  • junio 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • enero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • agosto 2017
  • julio 2017
  • junio 2017
  • febrero 2015
  • octubre 2014
  • junio 2014
  • marzo 2014
  • febrero 2014
  • enero 2014
  • diciembre 2013
  • septiembre 2013
  • agosto 2013
  • julio 2013
  • junio 2013
  • abril 2013
  • febrero 2013
  • enero 2013
  • diciembre 2012
  • noviembre 2012
  • septiembre 2012
  • agosto 2012
  • junio 2012
  • mayo 2012
  • abril 2012
  • marzo 2012
  • febrero 2012
  • enero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • julio 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • marzo 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • septiembre 2010
  • agosto 2010
  • julio 2010
  • junio 2010
  • mayo 2010
  • abril 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • julio 2007
  • junio 2007
  • mayo 2007
  • abril 2007
  • marzo 2007
  • febrero 2007
  • enero 2007
  • diciembre 2006
  • noviembre 2006
  • octubre 2006
  • septiembre 2006
  • agosto 2006
  • julio 2006
  • junio 2006
  • mayo 2006
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • twitter

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.