Wie lösen Sie die übliche Namenskollision zwischen Typ und Objekt auf?

Question

Da die Standard-C#-Konvention darin besteht, den ersten Buchstaben von öffentlichen Eigenschaften groß zu schreiben, verhindert die alte C++-Konvention der Großschreibung für Typnamen und der Kleinschreibung für Nicht-Typnamen nicht die klassische Namenskollision, bei der der offensichtlichste Objektname mit dem Typnamen übereinstimmt:

class FooManager
{
    public BarManager BarManager { get; set; } // Feels very wrong.
                                               // Recommended naming convention?
    public int DoIt()
    {
         // 1st and 2nd Bar Manager are different symbols 
         return BarManager.Blarb + BarManager.StaticBlarb;                                                                          
    }
}

class BarManager
{
    public        int Blarb { get; set; }
    public static int StaticBlarb { get; set; }
}

Es scheint zu kompilieren, aber es fühlt sich so falsch an. Gibt es eine empfohlene Benennungskonvention, um dies zu vermeiden?

Answer 1

Es ist nicht ungewöhnlich, dass ein Typ und eine Eigenschaft genau denselben Namen tragen. Ja, es sieht ein wenig seltsam aus, aber die Umbenennung von Eigenschaften zur Vermeidung dieses Konflikts sieht zugegebenermaßen noch seltsamer aus.

Eric Lippert hatte einen Blogbeitrag zu genau diesem Thema .

Für den Compiler gibt es jedoch keine Zweideutigkeit.

Answer 2

Die C#-Konvention ist es, Eigenschaften auf die gleiche Weise zu benennen, wie Sie Ihre Klassen benennen. Der Grund, warum Sie das für falsch halten, ist, dass Sie aus einem anderen Umfeld kommen. Aber wenn Sie eine Weile damit arbeiten, werden Sie feststellen, dass es Ihnen keine Probleme bereitet und sich ziemlich natürlich anfühlt, wenn Sie sich daran gewöhnt haben. Es gibt keine Stelle, an der es in irgendeiner Weise kollidieren würde. Ich (als c#-Entwickler) habe das Gefühl, dass sich die Konvention der Kleinschreibung für Eigenschaften falsch anfühlt. Man muss sich einfach daran gewöhnen.

Answer 3

Ich bin mit diesem ehrlich gesagt okay - wenn Ihre statischen Methoden/Mitglieder nicht offensichtlich statisch durch Namen und durch Zweck sind, haben Sie größere Probleme als Namenskollision.

Answer 4

Ich glaube nicht, dass dies jemals ein Problem für mich war. Es folgen die allgemeinen Konventionen für Eigenschaften. Nur Sache helpful sein könnte getting used zu diesen....

• Pascal Case, keine Unterstriche.
• Versuchen Sie, Abkürzungen zu vermeiden.
• Die Mitglieder müssen sich um mehr als einen Fall unterscheiden unterscheiden, damit sie von der case-insensitive Sprachen wie Visual Basic .NET.

Warum: Diese Konvention ist konsequent mit dem .NET Framework und ist einfach zu lesen. lesen. wie

public int RecordId

Hinweis : NET-Programmierstandards und Benennungskonventionen

Sehen Sie sich auch dies an: Allgemeine Benennungskonventionen

Answer 5

Ich möchte dies abmildern, indem ich sage, dass mich die Kollision nicht stört, da der Compiler sie ausgleichen kann. Allerdings Ich möchte andere Lösungen anbieten, die ich gesehen habe, und andere für mich entscheiden lassen... Ich glaube, hier ist das (für mich) hässliche Muster der Verwendung von My* entstanden.

Zum Beispiel:

public class Foo { /* ... */ }

public class Bar
{
    public Foo MyFoo { get; set; }
    // ...
}