C # использование директивы пространства имен во вложенных пространствах имен

Question

Правильно, я обычно использовал директивы using следующим образом

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace AwesomeLib
{
  //awesome award winning class declarations making use of Linq
}

я недавно видел примеры таких как

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace AwesomeLib
{
  //awesome award winning class declarations making use of Linq

  namespace DataLibrary
  {
    using System.Data;

    //Data access layers and whatnot
  }

}

Конечно, я понимаю, что могу использовать USING внутри моей декларации пространства имен. Такая вещь имеет смысл для меня, если ваши пространства имен находятся в одном корне (они организованы).

System;
namespace 1 {}
namespace 2 
{
  System.data;
}

Но как быть с вложенными пространствами имен? Лично я бы оставил все объявления ИСПОЛЬЗОВАНИЯ наверху, где вы можете легко их найти. Вместо этого похоже, что они распространяются по всему исходному файлу.

Есть ли польза от директив USING, используемых таким образом во вложенных пространствах имен? Например, управление памятью или JIT-компилятор?

Answer 1

Код IL не отражает C # using

Производительность во время исполнения

Есть ли польза от использования директивы, используемые таким образом в вложенные пространства имен? типа памяти управление или JIT-компилятор?

Поскольку вы спрашиваете о производительности во время выполнения, рассмотрим, что происходит под исходным кодом.

Если вы посмотрите на скомпилированный код IL с помощью инструмента Microsoft IL Diassembler (как мы делаем здесь), вы увидите, что все имена классов полностью определены, независимо от того, как программист использовал using в исходном коде.

В в следующем примере скомпилированного кода IL обратите внимание, что «быстрый» механизм не виден, хотя using был в исходных файлах исходного кода C #. Например, IL описывает один длинный extends [System.Web]System.Web.UI.Page, тогда как C # использовал бы : Page, а также using System.Web.UI; (два отдельных оператора).

// ***** Compiled MSIL CODE ****
// Notice all fully qualified classes throughout.
// 

.class public auto ansi beforefieldinit WebApplication1.process
       extends [System.Web]System.Web.UI.Page
{
  .field family class [System.Web]System.Web.UI.HtmlControls.HtmlForm form1
  .method family hidebysig instance void 
          Page_Load(object sender,
                    class [mscorlib]System.EventArgs e) cil managed
  {
    // Code size       95 (0x5f)
    .maxstack  4
    .locals init ([0] string strName,
             [1] string strTime)
    IL_0000:  nop
    IL_0001:  ldarg.0
    IL_0002:  call       instance class [System.Web]System.Web.HttpRequest [System.Web]System.Web.UI.Page::get_Request()
    IL_0007:  ldstr      "name"
    IL_000c:  callvirt   instance string [System.Web]System.Web.HttpRequest::get_Item(string)

В скомпилированном IL все классы полностью квалифицированы независимо.

Это означает, что нет никаких преимуществ или недостатков в производительности во время выполнения на основе времени разработки using операторов.

Время компиляции

В зависимости от того, как вы расскажете о своих using s и namespace s в исходном коде, может быть больше или меньше ключевых слов, которые можно найти вокруг. Компилятор должен видеть их все и обрабатывать их все, но в целом производительность компиляции будет незначительной для чего-то такого тривиального по сравнению со всеми вещами, которые компилятор должен сделать для создания готового продукта.

Преимущества времени проектирования

пространства имен - это организационная техника, а using - это способ управления ими на уровне исходного кода (и указания компилятору, как вы их используете, чтобы он мог соответствующим образом скомпилировать программу). Когда источник C # указывает using System.Web.UI;, ничего не импортируется, и размер файла не увеличивается (поскольку на сборку уже ссылаются); вместо этого using просто применяет более короткий синтаксис к содержимому этого пространства имен изнутри области, в которой используется using, будь то во всей области файла или объявленной области пространства имен внутри файл.

Преимущество для программиста заключается в уменьшении неоднозначных конфликтов имен классов между несколькими пространствами имен using s, если они используются разумно.

Организация пространств имен исходного кода по-разному представлена ​​в скомпилированном коде IL (как видно из приведенного выше примера).

Answer 2

Нет пользы для сгенерированного промежуточного языка. Поскольку CIL является входом для JIT-компилятора, это также не изменяется.

Поскольку вы говорите о передовых практиках, лучше всего иметь только один класс на файл, поэтому у вас также будет только одно пространство имен.

Answer 3

Когда вы находитесь в области, которая не нуждается в System.Data, лучше, если IntelliSense не вызывает членов System.Data, чтобы просто связываться с другими вещами, которые вы ищете

О некоторой проблеме с производительностью - я не думаю, что важно, как вы предпочитаете ее использовать ...

Answer 4

Из правил Style Cop :

1. Размещение директив using-alias в пространстве имен устраняет путаницу компилятора между конфликтующими типами.
2. Если в одном файле определено несколько пространств имен, размещение с использованием директив в элементах пространства имен определяет ссылки и псевдонимы.

Answer 5

Условия использования только помогают сделать ваш код более понятным, они не влияют на производительность вашего кода AFAIK.

То же самое относится к пространствам имен - вы можете поместить все свои классы в глобальное пространство имен и назвать их Class1, Class2 и т. Д., И ваш код будет работать так же хорошо. Но поддерживать это было бы кошмаром!

Так что они оба здесь, чтобы помочь вам, кодировщик, они не влияют на скомпилированный код.