Typ-/Namespace-Aliaskonventionen in C#

Question

Gibt es festgelegte Benennungs- oder Kodierungskonventionen für die Definition von namespace or type aliases in C#?

Für diejenigen, die nicht wissen, hat die C# -Sprache eine Funktion, wo Aliase lokal für eine Datei für Namespaces und Typen definiert werden können. Dies kann nützlich sein, wenn Namenskonflikte mit Bibliotheken von Drittanbietern auftreten und Typnamen in Ihrem Code verkürzt werden. Unten ist ein Beispiel dafür, wie es aussieht.

using Forms = System.Windows.Forms; 

Die meisten Beispiele, die ich rund um die Web gesehen haben neigen dazu, über unabbreviated aktivierten Namen als Aliasnamen wie die Alias ​​Forms im Beispiel zu verwenden. An einigen Stellen einschließlich der official MSDN page, die Beispiel mit einem Alias ​​von colAlias ​​ für den Namespace System.Collections erklärt. Um es komplizierter zu machen, kann es eine Präferenz für einige geben, unterschiedliche Richtlinien zu wählen, abhängig davon, ob ein Namespace-Alias ​​oder ein Typ-Alias ​​definiert wird.

Um einige Hintergrundinformationen zu geben, warum ich mich für irgendwelche Richtlinien mit Alias-Namen interessiere, werde ich erklären, was ich mache. In einem kürzlichen Projekt habe ich begonnen, ein Muster zu vereinfachen, bei dem ich mehrere Klassen habe, die von einer generischen Basisklasse erben, die komplexe Typargumente akzeptiert, indem ich Typaliasnamen verwende.

Mit dieser Technik wird das untenstehende komplexe Beispiel viel lesbarer, sobald Aliase verwendet werden.

public class MyClass: MyGenericBaseClass<TripleLindyFancyAlgorithm<List<SomeValueType>>, List<SomeValueType>> 
{ 
    public override List<SomeValueType> DoSomething(TripleLindyFancyAlgorithm<List<SomeValueType>> operation) 
    { 
     // ... 
    } 
} 

Und unter der MUST-Cleaner-Version mit Typ Aliase.

using Result = List<SomeValueType>; 
using Algorithm = TripleLindyFancyAlgorithm<List<SomeValueType>>; // Note: cannot reference an alias within an alias definition! 

public class MyClass: MyGenericBaseClass<Algorithm, Result> 
{ 
    public override Result DoSomething(Algorithm operation) 
    { 
     // ... 
    } 
} 

Obwohl dies viel mehr simpel aussieht, ist es leicht zu vergessen, dass ein Alias ​​wie Ergebnis eigentlich nur ein Alias ​​für Liste ist und dass es kein tatsächlicher Typ Ergebnis genannt. Um die Konzepte visuell zu trennen, beachte ich, dass man einigen Präfix-Konventionen folgen muss, die der Verwendung von Unterstrichen "_" vor privaten Mitgliedern ähnlich sind, um Typ-Aliase von tatsächlichen Typen zu unterscheiden. Bevor ich das mache, möchte ich jedoch sicherstellen, dass ich das Rad nicht neu erfinde, da es dort vielleicht schon etabliertere Konventionen gibt.

Answer 1

Namespace-Aliase sind kein häufiges Merkmal der meisten Codebasen - der letzte Ort, an dem ich es benutzt habe, war dem Seniorentwickler nicht vertraut, obwohl er viele Jahre mit C# gearbeitet hat.

Da es selten ist, wurden Konventionen dafür nicht entwickelt.

Ich würde sagen, wenn Sie Aliase verwenden möchten, besprechen Sie dies mit Ihrem Team, um Ihre eigene Konvention zu erstellen.

Mehrere verschiedene Arten Ich habe Aliase gesehen verwendet:

• Eine Abkürzung des Namespace. Normalerweise die Großbuchstaben im Namensraum.
• Das Ende des Namensraums - wenn Plural de-pluralisiert.
• Ein beschreibender Kurzname.

Answer 2

Persönlich würde ich es nur verwenden, um intelli-sense sauber zu halten.

Wenn Sie Typen umbenennen, öffnen Sie die Pandora-Box für Wartungsprogrammierer.

Answer 3

Ich würde nur Aliase im Falle von Namespace-Konflikt verwenden (d. H. Nur wenn ich hatte zu).

Für mich zumindest jede andere Verwendung ist nur verwirrend und eine Ablenkung.

Answer 4

Die beiden häufigsten Fälle für Namespace-Aliase sind:

1. ich es sah und ich benutze es (als Trend)
2. I Port-Code aus einer anderen Sprache

Für der erste Fall, kein Kommentar. Für die zweiten Code aus C und Verwendung Namespace-Aliase für Praktikabilität ein gutes Beispiel wie portiert:

using i64 = System.Int64; 
using u8 = System.Byte; 
using u32 = System.UInt32; 
using u64 = System.UInt64; 

Auch wenn Sie die oben genannte Aliase als faul Programmierung betrachten, sie helfen, Fehler zu vermeiden.

Answer 5

Ich denke, die Leute, die geneigt sind, sie überhaupt nicht zu verwenden sind geben die Antwort, die Sie gefragt haben. Das ist die Konvention. Das soll nicht heißen, dass es nicht nützlich sein kann, aber es nicht zu verwenden, bleibt die Norm.

Answer 6

Sie könnten eine Konvention übernehmen, um sie für die Abstraktion zu verwenden.

using Id = System.Int32; 

Auf diese Weise können Sie einfach ersetzen Sie einfach die Zeile mit

using Id = System.Guid; 

an einem gewissen Punkt und kein anderer Code würde sich ändern müssen (vorausgesetzt, Sie nicht durch die Abstraktion hat spähte Abhängigkeiten von der erstellen tatsächlicher Typ ...)

Answer 7

ich nur im allgemeinen sie verwenden, wenn ich zwei ähnlich benannte Klassen in unterschiedlichen Namensräumen verwenden muß, und will nicht vollständig den Typen im Code angeben:

using xItem = My.Project.NameSpace.Item; 
using yItem = Your.ThirdParty.Framework.Item;