2010-05-18 5 views
10

Ich stoße oft genug darauf, dass ich dachte, ich würde sehen, was andere darüber zu sagen haben.Was ist eine gute Benennungskonvention, um einen Klassennamen von einer Eigenschaft in C# zu unterscheiden?

Mit den StyleCop-Konventionen finde ich oft einen Eigenschaftsnamen, der sich kaum von dem Klassennamen unterscheidet, auf den er zugreift. Zum Beispiel:

public class ProjectManager 
{ 
// Stuff here 
} 

public class OtherClass 
{ 
    private ProjectManager ProjectManager { get; set; } 
} 

Es kompiliert und ausgeführt wird, aber scheint, wie es eine einfache Möglichkeit wäre, die Dinge zu verwirren, auch bei der Verwendung von „this“.

+9

Das Color Color-Problem. Wenn der beste Name für die Eigenschaft * ist * der Klassenname, gehen Sie mit. Andernfalls könnten Sie sich angewöhnen, Ihre Eigentums- und/oder Klassennamen unnötig zu komplizieren. –

+0

Ich stimme zu, es verwirrt mich auch. this.ProjectManager löst es jedoch ziemlich gut. – kenny

+1

Tatsächlich ist dies das berühmte "Color Color" -Problem. Die C# -Sprache wurde sorgfältig entworfen, so dass Sie mit diesem Muster durchkommen können, aber es verursacht einige interessante Eckfälle. Für eine Analyse der Konsequenzen dieser Regeln siehe meinen Artikel: http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx –

Antwort

11

Dies ist tatsächlich ein sehr häufiges Muster in der .Net-Programmierung. Besonders bei Enum-Typen und -Mitgliedern ist es die .Net Design Guidelines empfohlene Art der Programmierung.

4.0-Design-Richtlinien Referenz

Während es ein wenig verwirrend sein kann, ist es nicht, wenn Sie es ein paar Mal gesehen haben. Die Werkzeuge unterstützen dieses Muster gut, und wenn man einen Typ und den anderen eine Instanz ist, ist es schwierig, sie versehentlich zu invertieren, ohne einen Kompilierungsfehler zu verursachen.

+0

Jared, könnten Sie die aktuelle Version dieses Links posten? Wenn .NET 1.1-Links veröffentlicht werden, landen einige Leute nach mehr Links, ohne zu merken, dass sie in der .NET 1.1-Welt sind. –

+0

@John, habe nicht einmal realisiert, dass ich mit den 1.1-Versionen verknüpft habe. Danke, dass du das verstanden hast. Aktualisiert für die 4.0 Richtlinien – JaredPar

+0

müssen wir Ihr Unternehmen auf .NET 3.5 oder .NET 2.0 im schlimmsten Fall aktualisieren. :-) –

4

Das ist eine typische Namenskonvention, wenn es nur eine einzige Eigenschaft vom Typ ProjectManager innerhalb einer bestimmten Klasse gibt. Es hört auf, verwirrend zu sein, weil es keine anderen Verwendungen des Typs ProjectManager gibt.

Natürlich, wenn es andere Verwendungen gibt, dann brauchen Sie andere Namen.

1

Ich stimme den anderen Antworten zu. Der Vollständigkeit halber finde ich manchmal einen Weg, den Klassennamen etwas mehr zu verallgemeinern. Ich verstehe Ihr Beispiel war nur ein Beispiel, aber eine Möglichkeit, es zu tun wäre:

public class Person 
{ 
    // Stuff here 
} 

public class OtherClass 
{ 
    private Person ProjectManager { get; set; } 
} 

Dies hilft es besser lesbar etwas zu machen. Aber es ist vollkommen akzeptabel (und sogar ermutigt), den gleichen Klassennamen und die gleiche Eigenschaft zu haben.

Verwandte Themen