Sollten 'using'-Direktiven innerhalb oder außerhalb des Namespace liegen?

Ich habe StyleCop über einen C # -Code ausgeführt und es wird immer wieder gemeldet, dass sich meine usingAnweisungen im Namespace befinden sollten.

Gibt es einen technischen Grund, die usingDirektiven innerhalb und nicht außerhalb des Namespace zu platzieren?

Es gibt tatsächlich einen (subtilen) Unterschied zwischen den beiden. Stellen Sie sich vor, Sie haben den folgenden Code in File1.cs:

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

Stellen Sie sich nun vor, jemand fügt dem Projekt eine weitere Datei (File2.cs) hinzu, die folgendermaßen aussieht:

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

Der Compiler sucht, Outerbevor er diese usingAnweisungen außerhalb des Namespace betrachtet, und findet Outer.Mathstattdessen statt System.Math. Leider (oder vielleicht zum Glück?) Hat Outer.Mathkein PIMitglied, so dass File1 jetzt kaputt ist.

Dies ändert sich, wenn Sie die usingNamespace-Deklaration wie folgt einfügen:

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

Jetzt sucht der Compiler Systemvor dem Suchen Outer, findet System.Mathund alles ist gut.

Einige würden argumentieren, dass Mathdies ein schlechter Name für eine benutzerdefinierte Klasse sein könnte, da bereits eine vorhanden ist System. Der Punkt hier ist nur , dass es ist ein Unterschied, und es wirkt sich auf die Wartbarkeit des Codes.

Es ist auch interessant festzustellen, was passiert, wenn Fooes sich im Namespace Outerbefindet und nicht Outer.Inner. In diesem Fall wird durch Hinzufügen Outer.Mathvon Datei2 Datei1 unterbrochen, unabhängig davon, wohin das usinggeht. Dies bedeutet, dass der Compiler den innersten umschließenden Namespace durchsucht, bevor er eine usingDirektive betrachtet.

Dieser Thread hat bereits einige großartige Antworten, aber ich denke, ich kann mit dieser zusätzlichen Antwort ein wenig mehr Details bringen.

Denken Sie zunächst daran, dass eine Namespace-Deklaration mit Punkten wie:

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

ist völlig gleichbedeutend mit:

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

Wenn Sie möchten, können Sie usingauf all diesen Ebenen Richtlinien festlegen. (Natürlich möchten wir usings nur an einem Ort haben, aber es wäre je nach Sprache legal.)

Die Regel zum Auflösen des implizierten Typs kann lose wie folgt angegeben werden: Durchsuchen Sie zuerst den innersten "Bereich" nach einer Übereinstimmung. Wenn dort nichts gefunden wird, gehen Sie eine Ebene zum nächsten Bereich und suchen Sie dort und so weiter . bis eine Übereinstimmung gefunden wird. Wenn auf einer bestimmten Ebene mehr als eine Übereinstimmung gefunden wird und einer der Typen aus der aktuellen Assembly stammt, wählen Sie diesen aus und geben Sie eine Compiler-Warnung aus. Andernfalls geben Sie auf (Fehler beim Kompilieren).

Lassen Sie uns nun in einem konkreten Beispiel mit den beiden Hauptkonventionen explizit erläutern, was dies bedeutet.

(1) Bei Verwendung außerhalb:

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

Im obigen Fall Ambiguouserfolgt die Suche in der folgenden Reihenfolge , um herauszufinden, um welchen Typ es sich handelt:

1. Verschachtelte Typen im Inneren C(einschließlich geerbter verschachtelter Typen)
2. Typen im aktuellen Namespace MyCorp.TheProduct.SomeModule.Utilities
3. Typen im Namespace MyCorp.TheProduct.SomeModule
4. Tippt ein MyCorp.TheProduct
5. Tippt ein MyCorp
6. Typen im Null- Namespace (dem globalen Namespace)
7. Arten in System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, undThirdParty

Die andere Konvention:

(2) Mit Verwendungen im Inneren:

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

Die Suche nach dem Typ erfolgt nun Ambiguousin dieser Reihenfolge:

1. Verschachtelte Typen im Inneren C(einschließlich geerbter verschachtelter Typen)
2. Typen im aktuellen Namespace MyCorp.TheProduct.SomeModule.Utilities
3. Arten in System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, undThirdParty
4. Typen im Namespace MyCorp.TheProduct.SomeModule
5. Tippt ein MyCorp
6. Typen im Null- Namespace (dem globalen Namespace)

(Beachten Sie, dass dies MyCorp.TheProductTeil von "3." war und daher zwischen "4." und "5." nicht benötigt wurde.)

Abschließende Bemerkungen

Unabhängig davon, ob Sie die Verwendungen innerhalb oder außerhalb der Namespace-Deklaration platzieren, besteht immer die Möglichkeit, dass jemand später einem der Namespaces mit höherer Priorität einen neuen Typ mit identischem Namen hinzufügt.

Wenn ein verschachtelter Namespace denselben Namen wie ein Typ hat, kann dies zu Problemen führen.

Es ist immer gefährlich, die Verwendungen von einem Ort an einen anderen zu verschieben, da sich die Suchhierarchie ändert und möglicherweise ein anderer Typ gefunden wird. Wählen Sie daher eine Konvention und halten Sie sich daran, damit Sie die Verwendung nie verschieben müssen.

In den Vorlagen von Visual Studio werden die Verwendungen standardmäßig außerhalb des Namespace platziert (z. B. wenn VS eine neue Klasse in einer neuen Datei generiert).

Ein (kleiner) Vorteil von usings mit außen ist , dass Sie können dann die Verwendung von Richtlinien für ein globales Attribut nutzen, zum Beispiel [assembly: ComVisible(false)]statt [assembly: System.Runtime.InteropServices.ComVisible(false)].

Wenn Sie es in die Namespaces einfügen, werden die Deklarationen lokal für diesen Namespace für die Datei (falls Sie mehrere Namespaces in der Datei haben). Wenn Sie jedoch nur einen Namespace pro Datei haben, spielt es keine große Rolle, ob sie nach draußen oder nach außen gehen innerhalb des Namespace.

using ThisNamespace.IsImported.InAllNamespaces.Here;

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

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

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Laut Hanselman - Verwenden von Richtlinie und Laden von Baugruppen ... und anderen derartigen Artikeln gibt es technisch keinen Unterschied.

Ich bevorzuge es, sie außerhalb von Namespaces zu platzieren.

Laut StyleCop-Dokumentation:

SA1200: UsingDirectivesMustBePlacedWithinNamespace

Ursache AC # mit der Direktive wird außerhalb eines Namespace-Elements platziert.

Regelbeschreibung Ein Verstoß gegen diese Regel tritt auf, wenn eine using-Direktive oder eine using-Alias-Direktive außerhalb eines Namespace-Elements platziert wird, es sei denn, die Datei enthält keine Namespace-Elemente.

Der folgende Code würde beispielsweise zu zwei Verstößen gegen diese Regel führen.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

Der folgende Code würde jedoch nicht zu Verstößen gegen diese Regel führen:

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

    public class Program
    {
    }
}

Dieser Code wird ohne Compilerfehler sauber kompiliert. Es ist jedoch unklar, welche Version des Guid-Typs zugewiesen wird. Wenn die using-Direktive wie unten gezeigt in den Namespace verschoben wird, tritt ein Compilerfehler auf:

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

Der Code schlägt bei dem folgenden Compilerfehler fehl, der in der Zeile mit gefunden wird Guid g = new Guid("hello");

CS0576: Der Namespace 'Microsoft.Sample' enthält eine Definition, die mit dem Alias ​​'Guid' in Konflikt steht.

Der Code erstellt einen Alias ​​für den System.Guid-Typ namens Guid und einen eigenen Typ namens Guid mit einer passenden Konstruktorschnittstelle. Später erstellt der Code eine Instanz vom Typ Guid. Um diese Instanz zu erstellen, muss der Compiler zwischen den beiden unterschiedlichen Definitionen von Guid wählen. Wenn die using-Alias-Direktive außerhalb des Namespace-Elements platziert wird, wählt der Compiler die lokale Definition von Guid aus, die im lokalen Namespace definiert ist, und ignoriert die using-Alias-Direktive, die außerhalb des Namespace definiert ist, vollständig. Dies ist beim Lesen des Codes leider nicht ersichtlich.

Wenn die using-Alias-Direktive jedoch im Namespace positioniert ist, muss der Compiler zwischen zwei verschiedenen, widersprüchlichen Guid-Typen wählen, die beide im selben Namespace definiert sind. Beide Typen bieten einen passenden Konstruktor. Der Compiler kann keine Entscheidung treffen und kennzeichnet daher den Compilerfehler.

Das Platzieren der using-alias-Direktive außerhalb des Namespace ist eine schlechte Praxis, da dies in Situationen wie dieser zu Verwirrung führen kann, in denen nicht klar ist, welche Version des Typs tatsächlich verwendet wird. Dies kann möglicherweise zu einem Fehler führen, der möglicherweise schwer zu diagnostizieren ist.

Durch das Platzieren von using-alias-Direktiven im Namespace-Element wird dies als Fehlerquelle beseitigt.

2. Mehrere Namespaces

Das Platzieren mehrerer Namespace-Elemente in einer einzelnen Datei ist im Allgemeinen eine schlechte Idee. In diesem Fall empfiehlt es sich jedoch, alle verwendeten Direktiven in jedem der Namespace-Elemente zu platzieren und nicht global am Anfang der Datei. Dies wird die Namespaces eng umrahmen und auch dazu beitragen, das oben beschriebene Verhalten zu vermeiden.

Es ist wichtig zu beachten, dass beim Schreiben von Code unter Verwendung von Anweisungen außerhalb des Namespace beim Verschieben dieser Anweisungen innerhalb des Namespace darauf geachtet werden sollte, dass dadurch die Semantik des Codes nicht geändert wird. Wie oben erläutert, kann der Compiler beim Platzieren von Direktiven mit Alias ​​innerhalb des Namespace-Elements zwischen widersprüchlichen Typen auf eine Weise wählen, die nicht auftritt, wenn die Direktiven außerhalb des Namespace platziert werden.

So beheben Sie Verstöße Um einen Verstoß gegen diese Regel zu beheben, verschieben Sie alle Direktiven und Alias-Direktiven innerhalb des Namespace-Elements.

Es gibt ein Problem beim Platzieren von using-Anweisungen im Namespace, wenn Sie Aliase verwenden möchten. Der Alias ​​profitiert nicht von den früheren usingAnweisungen und muss vollständig qualifiziert sein.

Erwägen:

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

    class MyClass
    {
    }
}

gegen:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

Dies kann besonders ausgeprägt sein, wenn Sie einen langwierigen Alias ​​wie den folgenden haben (so habe ich das Problem gefunden):

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

Mit usingAnweisungen im Namespace wird es plötzlich:

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

Nicht hübsch.

Wie Jeppe Stig Nielsen sagte , hat dieser Thread bereits großartige Antworten, aber ich dachte, dass diese ziemlich offensichtliche Subtilität auch erwähnenswert ist.

using Anweisungen, die in Namespaces angegeben werden, können zu kürzerem Code führen, da sie nicht vollständig qualifiziert sein müssen, wie wenn sie außen angegeben werden.

Das folgende Beispiel funktioniert, da sich die Typen Foound Barbeide im selben globalen Namespace befinden Outer.

Angenommen, die Codedatei Foo.cs :

namespace Outer.Inner
{
    class Foo { }
}

Und Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

Das kann den äußeren Namespace in der usingDirektive weglassen , kurz:

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Eine Falte, auf die ich gestoßen bin (die in anderen Antworten nicht behandelt wird):

Angenommen, Sie haben folgende Namespaces:

• Etwas anderes
• Parent.Something.Other

Wenn Sie using Something.Other außerhalb von a verwenden namespace Parent, bezieht es sich auf das erste (Something.Other).

Wenn Sie es jedoch innerhalb dieser Namespace-Deklaration verwenden, bezieht es sich auf die zweite (Parent.Something.Other)!

Es gibt eine einfache Lösung: Fügen Sie das global::Präfix " " hinzu: docs

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

Die technischen Gründe werden in den Antworten diskutiert und ich denke, dass es am Ende um die persönlichen Vorlieben geht, da der Unterschied nicht so groß ist und es für beide Kompromisse gibt. Die Standardvorlage von Visual Studio zum Erstellen von .csDateien verwendet usingAnweisungen außerhalb von Namespaces, z

Sie können stylecop anpassen, um usingAnweisungen außerhalb von Namespaces zu überprüfen, indem Sie eine stylecop.jsonDatei im Stammverzeichnis der Projektdatei wie folgt hinzufügen :

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

Sie können diese Konfigurationsdatei auf Lösungsebene erstellen und als "Vorhandene Linkdatei" zu Ihren Projekten hinzufügen, um die Konfiguration auch für alle Ihre Projekte freizugeben.

Eine andere Subtilität, von der ich nicht glaube, dass sie von den anderen Antworten abgedeckt wurde, ist, wenn Sie eine Klasse und einen Namespace mit demselben Namen haben.

Wenn Sie den Import im Namespace haben, wird die Klasse gefunden. Wenn sich der Import außerhalb des Namespace befindet, wird der Import ignoriert und die Klasse und der Namespace müssen vollständig qualifiziert sein.

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

Es ist eine bessere Vorgehensweise, wenn diejenigen, die standardmäßig " Referenzen " verwenden, die in Ihrer Quelllösung verwendet werden, außerhalb der Namespaces liegen sollten und diejenigen, die "neu hinzugefügte Referenzen" sind, eine gute Vorgehensweise sind, wenn Sie sie in den Namespace einfügen. Hiermit wird unterschieden, welche Referenzen hinzugefügt werden.