Czy dyrektywy „używające” powinny znajdować się w przestrzeni nazw, czy poza nią?

Używam StyleCop na pewnym kodzie C # i ciągle zgłasza, że ​​moje usingdyrektywy powinny znajdować się w przestrzeni nazw.

Czy istnieje techniczny powód, aby umieścić usingdyrektywy w środku zamiast poza przestrzenią nazw?

W rzeczywistości istnieje (subtelna) różnica między nimi. Wyobraź sobie, że masz następujący kod w pliku File1.cs:

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

Teraz wyobraź sobie, że ktoś dodaje do projektu kolejny plik (File2.cs), który wygląda następująco:

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

Kompilator wyszukuje Outerprzed spojrzeniem na te usingdyrektywy poza przestrzenią nazw, więc znajduje Outer.Mathzamiast System.Math. Niestety (a może na szczęście?) Nie Outer.Mathma PIczłonka, więc File1 jest teraz zepsuty.

Zmienia się to, jeśli umieścisz usingwewnątrz deklaracji przestrzeni nazw, co następuje:

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

Teraz kompilator wyszukuje Systemprzed wyszukiwaniem Outer, znajduje System.Mathi wszystko jest w porządku.

Niektórzy twierdzą, że Mathmoże to być zła nazwa dla klasy zdefiniowanej przez użytkownika, ponieważ jest już w niej jedna System; Chodzi o to tylko, że nie ma różnicy, a to wpływa na łatwość konserwacji swojego kodu.

Interesujące jest również odnotowanie, co się stanie, jeśli Foobędzie w przestrzeni nazw Outer, a nie Outer.Inner. W takim przypadku dodanie Outer.Mathdo pliku 2 powoduje uszkodzenie pliku 1 bez względu na to, dokąd usingidzie. Oznacza to, że kompilator przeszukuje najbardziej wewnętrzną obejmującą przestrzeń nazw, zanim zajmie się jakąkolwiek usingdyrektywą.

Wątek ten ma już kilka świetnych odpowiedzi, ale wydaje mi się, że dzięki tej dodatkowej odpowiedzi mogę przedstawić nieco więcej szczegółów.

Najpierw pamiętaj, że deklaracja przestrzeni nazw z kropkami, np .:

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

jest całkowicie równoważny z:

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

Jeśli chcesz, możesz zastosować usingdyrektywy na wszystkich tych poziomach. (Oczywiście chcemy mieć usingtylko w jednym miejscu, ale byłoby to zgodne z prawem w zależności od języka).

Regułę rozstrzygania, który typ jest domyślny, można luźno sformułować w następujący sposób: Najpierw wyszukaj najbardziej wewnętrzny „zakres” dopasowania, jeśli nic nie zostanie znalezione, przejdź o jeden poziom do następnego zakresu i wyszukaj tam itd. , aż do znalezienia dopasowania. Jeśli na pewnym poziomie znaleziono więcej niż jedno dopasowanie, jeśli jeden z typów pochodzi z bieżącego zestawu, wybierz go i wyślij ostrzeżenie kompilatora. W przeciwnym razie zrezygnuj (błąd czasu kompilacji).

Wyjaśnijmy teraz, co to oznacza w konkretnym przykładzie z dwoma głównymi konwencjami.

(1) Przy zastosowaniach na zewnątrz:

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;
    }
}

W powyższym przypadku, aby dowiedzieć się, jaki Ambiguousjest typ , wyszukiwanie odbywa się w następującej kolejności:

1. Typy zagnieżdżone w środku C(w tym dziedziczone typy zagnieżdżone)
2. Wpisuje w bieżącej przestrzeni nazw MyCorp.TheProduct.SomeModule.Utilities
3. Typy w przestrzeni nazw MyCorp.TheProduct.SomeModule
4. Wpisuje w MyCorp.TheProduct
5. Wpisuje w MyCorp
6. Typy w pustej przestrzeni nazw (globalnej przestrzeni nazw)
7. Rodzaje w System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, iThirdParty

Druga konwencja:

(2) Przy użyciu wewnątrz:

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;
    }
}

Teraz wyszukaj typ Ambiguousidzie w następującej kolejności:

1. Typy zagnieżdżone w środku C(w tym dziedziczone typy zagnieżdżone)
2. Wpisuje w bieżącej przestrzeni nazw MyCorp.TheProduct.SomeModule.Utilities
3. Rodzaje w System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, iThirdParty
4. Typy w przestrzeni nazw MyCorp.TheProduct.SomeModule
5. Wpisuje w MyCorp
6. Typy w pustej przestrzeni nazw (globalnej przestrzeni nazw)

(Należy pamiętać, że MyCorp.TheProductbył on częścią „3.” i dlatego nie był potrzebny między „4.” a „5.”.)

Uwagi końcowe

Bez względu na to, czy umieścisz użytkowanie w deklaracji przestrzeni nazw, czy poza nią, zawsze istnieje możliwość, że ktoś później doda nowy typ o identycznej nazwie do jednej z przestrzeni nazw o wyższym priorytecie.

Ponadto, jeśli zagnieżdżona przestrzeń nazw ma taką samą nazwę jak typ, może to powodować problemy.

Przenoszenie zastosowań z jednej lokalizacji do innej zawsze jest niebezpieczne, ponieważ zmienia się hierarchia wyszukiwania i można znaleźć inny typ. Dlatego wybierz jedną konwencję i trzymaj się jej, abyś nigdy nie musiał przenosić usług.

Szablony Visual Studio domyślnie umieszczają zastosowania poza obszarem nazw (na przykład, jeśli VS wygeneruje nową klasę w nowym pliku).

Jedną (niewielką) zaletą korzystania z usług na zewnątrz jest to, że można następnie użyć dyrektyw używania dla atrybutu globalnego, na przykład [assembly: ComVisible(false)]zamiast [assembly: System.Runtime.InteropServices.ComVisible(false)].

Umieszczenie go w przestrzeniach nazw powoduje, że deklaracje są lokalne dla tej przestrzeni nazw dla pliku (w przypadku, gdy w pliku znajduje się wiele przestrzeni nazw), ale jeśli masz tylko jedną przestrzeń nazw dla pliku, to nie ma znaczenia, czy wychodzą na zewnątrz, czy w przestrzeni nazw.

using ThisNamespace.IsImported.InAllNamespaces.Here;

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

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

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Według Hanselmana - Korzystanie z dyrektywy i ładowania zespołu ... i innych tego typu artykułów nie ma technicznej różnicy.

Wolę umieszczać je poza przestrzenią nazw.

Zgodnie z dokumentacją StyleCop:

SA1200: UsingDirectivesMustBePlacedWithinNamespace

Przyczyna AC # za pomocą dyrektywy jest umieszczony poza elementem przestrzeni nazw.

Opis reguły Naruszenie tej reguły występuje, gdy dyrektywa using lub dyrektywa using-alias zostanie umieszczona poza elementem przestrzeni nazw, chyba że plik nie zawiera żadnych elementów przestrzeni nazw.

Na przykład poniższy kod spowodowałby dwa naruszenia tej reguły.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

Poniższy kod nie spowoduje jednak naruszenia tej reguły:

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

    public class Program
    {
    }
}

Ten kod skompiluje się czysto, bez żadnych błędów kompilatora. Nie jest jednak jasne, która wersja typu Guid jest przydzielana. Jeśli dyrektywa using zostanie przeniesiona do przestrzeni nazw, jak pokazano poniżej, wystąpi błąd kompilatora:

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");
        }
    }
}

Kod kończy się niepowodzeniem w przypadku następującego błędu kompilatora, znalezionego w wierszu zawierającym Guid g = new Guid("hello");

CS0576: Przestrzeń nazw „Microsoft.Sample” zawiera definicję sprzeczną z aliasem „Guid”

Kod tworzy alias typu System.Guid o nazwie Guid, a także tworzy własny typ o nazwie Guid z pasującym interfejsem konstruktora. Później kod tworzy instancję typu Guid. Aby utworzyć to wystąpienie, kompilator musi wybrać jedną z dwóch różnych definicji Guid. Kiedy dyrektywa using-alias zostanie umieszczona poza elementem przestrzeni nazw, kompilator wybierze lokalną definicję Guid zdefiniowaną w lokalnej przestrzeni nazw i całkowicie zignoruje dyrektywę using-alias zdefiniowaną poza przestrzenią nazw. To niestety nie jest oczywiste podczas czytania kodu.

Gdy dyrektywa using-alias znajduje się w obszarze nazw, kompilator musi jednak wybierać między dwoma różnymi, sprzecznymi typami Guid, które są zdefiniowane w tej samej przestrzeni nazw. Oba te typy zapewniają zgodnego konstruktora. Kompilator nie może podjąć decyzji, więc oznacza błąd kompilatora.

Umieszczenie dyrektywy using-alias poza przestrzenią nazw jest złą praktyką, ponieważ może prowadzić do nieporozumień w sytuacjach takich jak ta, gdzie nie jest oczywiste, która wersja tego typu jest faktycznie używana. Może to potencjalnie prowadzić do błędu, który może być trudny do zdiagnozowania.

Umieszczenie dyrektyw przy użyciu aliasu w elemencie przestrzeni nazw eliminuje to jako źródło błędów.

2. Wiele przestrzeni nazw

Umieszczanie wielu elementów przestrzeni nazw w jednym pliku jest na ogół złym pomysłem, ale jeśli i kiedy to zostanie zrobione, dobrym pomysłem jest umieszczenie wszystkich za pomocą dyrektyw w obrębie każdego z elementów przestrzeni nazw, a nie globalnie na górze pliku. Spowoduje to ścisłe zawężenie przestrzeni nazw, a także pomoże uniknąć opisanych powyżej zachowań.

Należy zauważyć, że kiedy kod został napisany przy użyciu dyrektyw umieszczonych poza przestrzenią nazw, należy zachować ostrożność podczas przenoszenia tych dyrektyw w przestrzeni nazw, aby upewnić się, że nie zmienia to semantyki kodu. Jak wyjaśniono powyżej, umieszczenie dyrektyw przy użyciu aliasu w elemencie przestrzeni nazw umożliwia kompilatorowi wybór między konfliktami typów w sposób, który nie nastąpi, gdy dyrektywy zostaną umieszczone poza przestrzenią nazw.

Jak naprawić naruszenia Aby naprawić naruszenie tej reguły, przenieś wszystkie za pomocą dyrektyw i dyrektyw przy użyciu aliasu w elemencie przestrzeni nazw.

Występuje problem z umieszczaniem instrukcji przy użyciu w przestrzeni nazw, gdy chcesz używać aliasów. Alias ​​nie korzysta z wcześniejszych usinginstrukcji i musi być w pełni kwalifikowany.

Rozważać:

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

    class MyClass
    {
    }
}

przeciw:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

Może to być szczególnie wyraźne, jeśli masz długi alias, taki jak następujący (tak znalazłem problem):

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

Dzięki usinginstrukcjom w przestrzeni nazw nagle staje się:

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

Nie ładna

Jak powiedział Jeppe Stig Nielsen , ten wątek ma już świetne odpowiedzi, ale myślałem, że o tej dość oczywistej subtelności warto też wspomnieć.

using dyrektywy określone w przestrzeniach nazw mogą tworzyć krótszy kod, ponieważ nie muszą być w pełni kwalifikowane, jak wtedy, gdy są określone na zewnątrz.

Poniższy przykład działa, ponieważ wszystkie typy Fooi Barto zarówno w tej samej przestrzeni nazw globalnej Outer.

Załóżmy plik kodu Foo.cs :

namespace Outer.Inner
{
    class Foo { }
}

I Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

W usingskrócie może to pomijać zewnętrzną przestrzeń nazw w dyrektywie:

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Jedna zmarszczka, na którą natknąłem się (która nie jest uwzględniona w innych odpowiedziach):

Załóżmy, że masz te przestrzenie nazw:

• Coś innego
• Parent.Something.Inne

Kiedy używasz using Something.Other poza a namespace Parent, odnosi się do pierwszego (Coś. Inne).

Jeśli jednak użyjesz go w deklaracji przestrzeni nazw, odnosi się do drugiej (Parent.Something.Other)!

Istnieje proste rozwiązanie: dodaj global::przedrostek „ ”: docs

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

Przyczyny techniczne są omówione w odpowiedziach i myślę, że w końcu chodzi o osobiste preferencje, ponieważ różnica nie jest tak duża, a obie są kompromisy. Domyślny szablon programu Visual Studio do tworzenia .csplików korzysta z usingdyrektyw poza obszarami nazw, np

Można dostosować stylecop, aby sprawdzać usingdyrektywy poza obszarami nazw, dodając stylecop.jsonplik do katalogu głównego pliku projektu w następujący sposób:

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

Możesz utworzyć ten plik konfiguracyjny na poziomie rozwiązania i dodać go do swoich projektów jako „Istniejący plik linku”, aby udostępnić konfigurację również we wszystkich swoich projektach.

Inna subtelność, która nie wydaje mi się, że została ujęta w innych odpowiedziach, dotyczy sytuacji, gdy masz klasę i przestrzeń nazw o tej samej nazwie.

Kiedy importujesz w przestrzeni nazw, znajdzie klasę. Jeśli import znajduje się poza obszarem nazw, wówczas import zostanie zignorowany, a klasa i przestrzeń nazw muszą być w pełni kwalifikowane.

//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.
        }
    }
}

Lepszą praktyką jest, aby te domyślne, które używają np. „ Referencji ” używanych w rozwiązaniu źródłowym, znajdowały się poza przestrzeniami nazw, a te, które są „nowymi dodanymi referencjami”, są dobrą praktyką, należy umieszczać je w przestrzeni nazw. Ma to na celu rozróżnienie, jakie odniesienia są dodawane.