Должны ли директивы using находиться внутри или вне пространства имен?

Я запускал StyleCop над кодом C #, и он продолжает сообщать, что мои usingдирективы должны быть внутри пространства имен.

Есть ли техническая причина для размещения usingдиректив внутри, а не вне пространства имен?

На самом деле есть (тонкая) разница между ними. Представьте, что у вас есть следующий код в File1.cs:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Теперь представьте, что кто-то добавляет в проект другой файл (File2.cs), который выглядит следующим образом:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

Компилятор ищет, Outerпрежде чем смотреть на эти usingдирективы вне пространства имен, поэтому он находит Outer.Mathвместо System.Math. К сожалению (или, возможно, к счастью?), Outer.MathНет PIчлена, поэтому File1 теперь не работает.

Это изменится, если вы поместите usingвнутреннюю декларацию пространства имен следующим образом:

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Теперь компилятор ищет Systemперед поиском Outer, находит System.Math, и все хорошо.

Некоторые утверждают, что это Mathможет быть плохое имя для пользовательского класса, поскольку он уже есть System; Дело здесь только в том, что есть разница, и это влияет на удобство сопровождения вашего кода.

Также интересно отметить, что происходит, если Fooнаходится в пространстве имен Outer, а не Outer.Inner. В этом случае добавление Outer.Mathв File2 нарушает работу File1 независимо от того, куда он usingидет. Это подразумевает, что компилятор ищет самое внутреннее пространство имен, прежде чем он смотрит на любую usingдирективу.

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

Во-первых, помните, что объявление пространства имен с точками, например:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    ...
}

полностью эквивалентно:

namespace MyCorp
{
    namespace TheProduct
    {
        namespace SomeModule
        {
            namespace Utilities
            {
                ...
            }
        }
    }
}

Если вы хотите, вы можете поместить usingдирективы на всех этих уровнях. (Конечно, мы хотим иметь usings только в одном месте, но это будет законно в зависимости от языка.)

Правило для определения того, какой тип подразумевается, можно условно сформулировать следующим образом: сначала ищите самую внутреннюю «область» для совпадения, если там ничего не найдено, переходите на один уровень к следующей области и ищите там, и так далее , пока совпадение не найдено. Если на каком-то уровне найдено более одного совпадения, если один из типов относится к текущей сборке, выберите его и выдайте предупреждение компилятора. В противном случае сдавайтесь (ошибка времени компиляции).

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

(1) с использованием снаружи:

using System;
using System.Collections.Generic;
using System.Linq;
//using MyCorp.TheProduct;  <-- uncommenting this would change nothing
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    class C
    {
        Ambiguous a;
    }
}

В приведенном выше случае, чтобы узнать, какой тип Ambiguous, поиск идет в следующем порядке:

1. Вложенные типы внутри C(включая унаследованные вложенные типы)
2. Типы в текущем пространстве имен MyCorp.TheProduct.SomeModule.Utilities
3. Типы в пространстве имен MyCorp.TheProduct.SomeModule
4. Типы в MyCorp.TheProduct
5. Типы в MyCorp
6. Типы в пустом пространстве имен (глобальное пространство имен)
7. Типы в System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, иThirdParty

Другое соглашение:

(2) с использованием внутри:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using MyCorp.TheProduct;                           // MyCorp can be left out; this using is NOT redundant
    using MyCorp.TheProduct.OtherModule;               // MyCorp.TheProduct can be left out
    using MyCorp.TheProduct.OtherModule.Integration;   // MyCorp.TheProduct can be left out
    using ThirdParty;

    class C
    {
        Ambiguous a;
    }
}

Теперь поиск по типу Ambiguousидет в следующем порядке:

1. Вложенные типы внутри C(включая унаследованные вложенные типы)
2. Типы в текущем пространстве имен MyCorp.TheProduct.SomeModule.Utilities
3. Типы в System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, иThirdParty
4. Типы в пространстве имен MyCorp.TheProduct.SomeModule
5. Типы в MyCorp
6. Типы в пустом пространстве имен (глобальное пространство имен)

(Обратите внимание, что это MyCorp.TheProductбыло частью «3» и поэтому не было необходимости между «4» и «5».)

Заключительные замечания

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

Кроме того, если вложенное пространство имен имеет то же имя, что и тип, это может вызвать проблемы.

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

Шаблоны Visual Studio по умолчанию помещают значения за пределы пространства имен (например, если вы заставляете VS генерировать новый класс в новом файле).

Одним (крошечным) преимуществом использования извне является то, что вы можете использовать директивы using для глобального атрибута, например, [assembly: ComVisible(false)]вместо [assembly: System.Runtime.InteropServices.ComVisible(false)].

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

using ThisNamespace.IsImported.InAllNamespaces.Here;

namespace Namespace1
{ 
   using ThisNamespace.IsImported.InNamespace1.AndNamespace2;

   namespace Namespace2
   { 
      using ThisNamespace.IsImported.InJustNamespace2;
   }       
}

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Согласно Hanselman - Использование директивы и сборки Загрузка ... и другие подобные статьи, технически нет никакой разницы.

Я предпочитаю размещать их вне пространства имен.

Согласно документации StyleCop:

SA1200: использованиеDirectivesMustBePlacedWithinNamespace

Причина. Директива AC # using размещена вне элемента пространства имен.

Описание правила Нарушение этого правила происходит, когда директива using или директива using-alias размещаются вне элемента пространства имен, если файл не содержит никаких элементов пространства имен.

Например, следующий код приведет к двум нарушениям этого правила.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

Однако следующий код не приведет к каким-либо нарушениям этого правила:

namespace Microsoft.Sample
{
    using System;
    using Guid = System.Guid;

    public class Program
    {
    }
}

Этот код будет компилироваться без ошибок компилятора. Однако неясно, какая версия типа Guid выделяется. Если директива using перемещается внутри пространства имен, как показано ниже, произойдет ошибка компилятора:

namespace Microsoft.Sample
{
    using Guid = System.Guid;
    public class Guid
    {
        public Guid(string s)
        {
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Guid g = new Guid("hello");
        }
    }
}

Сбой кода при следующей ошибке компилятора, найденной в строке, содержащей Guid g = new Guid("hello");

CS0576: пространство имен «Microsoft.Sample» содержит определение, конфликтующее с псевдонимом «Guid»

Код создает псевдоним для типа System.Guid с именем Guid, а также создает свой собственный тип с именем Guid с соответствующим интерфейсом конструктора. Позже код создает экземпляр типа Guid. Чтобы создать этот экземпляр, компилятор должен выбрать между двумя различными определениями Guid. Когда директива using-alias размещается вне элемента пространства имен, компилятор выбирает локальное определение Guid, определенное в локальном пространстве имен, и полностью игнорирует директиву using-alias, определенную вне пространства имен. Это, к сожалению, неочевидно при чтении кода.

Однако, когда директива using-alias размещается в пространстве имен, компилятору приходится выбирать между двумя различными, конфликтующими типами Guid, оба определены в одном и том же пространстве имен. Оба эти типа предоставляют соответствующий конструктор. Компилятор не может принять решение, поэтому он отмечает ошибку компилятора.

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

Размещение директив using-alias в элементе namespace устраняет это как источник ошибок.

2. Несколько пространств имен

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

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

Как исправить нарушения Чтобы исправить нарушение этого правила, переместите все с использованием директив и директив using-alias в элемент пространства имен.

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

Рассматривать:

namespace MyNamespace
{
    using System;
    using MyAlias = System.DateTime;

    class MyClass
    {
    }
}

против:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

Это может быть особенно заметно, если у вас есть длинный псевдоним, такой как следующий (вот как я нашел проблему):

using MyAlias = Tuple<Expression<Func<DateTime, object>>, Expression<Func<TimeSpan, object>>>;

С usingзаявлениями внутри пространства имен это внезапно становится:

using MyAlias = System.Tuple<System.Linq.Expressions.Expression<System.Func<System.DateTime, object>>, System.Linq.Expressions.Expression<System.Func<System.TimeSpan, object>>>;

Не красиво

Как сказал Джепп Стиг Нильсен , у этой ветки уже есть отличные ответы, но я подумал, что эту довольно очевидную тонкость тоже стоит упомянуть.

using Директивы, указанные внутри пространств имен, могут привести к сокращению кода, поскольку они не должны быть полностью квалифицированными, как если бы они были указаны снаружи.

Следующий пример работает, потому что типы Fooи Barоба находятся в одном глобальном пространстве имен Outer.

Предположим, файл кода Foo.cs :

namespace Outer.Inner
{
    class Foo { }
}

И Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

Это может опустить внешнее пространство имен в usingдирективе, для краткости:

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Одна морщина, с которой я столкнулся (это не покрыто другими ответами):

Предположим, у вас есть эти пространства имен:

• Something.Other
• Parent.Something.Other

При использовании using Something.Other снаружи от namespace Parent, это относится к первому (Something.Other).

Однако, если вы используете его внутри этого объявления пространства имен, оно ссылается на второе (Parent.Something.Other)!

Есть простое решение: добавить global::префикс " ": docs

namespace Parent
{
   using global::Something.Other;
   // etc
}

Технические причины обсуждаются в ответах , и я думаю , что речь идет о личных предпочтениях в конце концов , так как разница не так уж большая , и есть компромиссы для обоих из них. Шаблон Visual Studio по умолчанию для создания .csфайлов использует usingдирективы вне пространств имен, например

Можно настроить stylecop для проверки usingдиректив вне пространств имен, добавив stylecop.jsonфайл в корень файла проекта с помощью следующего:

{
  "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
    "orderingRules": {
      "usingDirectivesPlacement": "outsideNamespace"
    }
  }
}

Вы можете создать этот файл конфигурации на уровне решения и добавить его в свои проекты как «Существующий файл ссылок», чтобы разделить конфигурацию также со всеми вашими проектами.

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

Когда у вас есть импорт внутри пространства имен, он найдет класс. Если импорт находится за пределами пространства имен, то импорт будет проигнорирован, а класс и пространство имен должны быть полностью квалифицированы.

//file1.cs
namespace Foo
{
    class Foo
    {
    }
}

//file2.cs
namespace ConsoleApp3
{
    using Foo;
    class Program
    {
        static void Main(string[] args)
        {
            //This will allow you to use the class
            Foo test = new Foo();
        }
    }
}

//file2.cs
using Foo; //Unused and redundant    
namespace Bar
{
    class Bar
    {
        Bar()
        {
            Foo.Foo test = new Foo.Foo();
            Foo test = new Foo(); //will give you an error that a namespace is being used like a class.
        }
    }
}

Рекомендуется, чтобы те, по умолчанию использующие, например, « ссылки », используемые в исходном решении, находились за пределами пространств имен, а те, которые являются «новой добавленной ссылкой», - это хорошая практика, если вы должны поместить его в пространство имен. Это должно отличить, какие ссылки добавляются.