2010-12-27 18 views
23

Erstens, ich weiß, dass diese Frage schon mehrmals gestellt wurde und dass es am Ende meist eine Frage der persönlichen Vorliebe ist, aber alle Threads über das Thema zu lesen, sind einige Dinge nicht klar mich.Namenskonvention für private Felder

Im Grunde sind die meisten Leute zumindest der Meinung, dass das öffentliche Mitglied PascalCased sein sollte, während private Mitglieder niedrigereCamelCased sein sollten.

Die Frage, die normalerweise Debatte bringt, ist, ob die privaten Mitglieder durch einen Unterstrich oder irgendetwas anderes vorangestellt werden sollen oder nicht. Prefixing verletzt mehrere StyleCop-Regeln (die aber natürlich deaktiviert werden können)

Die Begründung, nicht Präfix ist, dass Sie dies verwenden sollten. stattdessen vorangestellt werden.

Das Problem, das ich habe, ist, dass ich nicht verstehe, wie es einen Unterschied macht? Ich meine, es ist nicht so, dass Sie dies nicht für ein öffentliches Mitglied in einer Klasse verwenden können.

Lassen Sie uns eine Klasse Kunden vorstellen, wie folgt aussehen:

class Customer 
{ 
    private int age; 

    public int Age 
    { 
     get { return this.age; } 
     set { this.age = value; } 
    } 
} 

(Offensichtlich in einem so einfachen Fall, ich eine autoproperty verwenden könnte, aber das ist nur ein Beispiel).

Wenn ich eine zweite Eigenschaft innerhalb dieser Klasse hinzufügte, würde mich nichts daran hindern, mit this.Age (die öffentliche Eigenschaft) und nicht mit this.age (dem privaten Feld) darauf zu verweisen. Manchmal könnte es sogar zulässig sein, wenn eine Überprüfung oder Formatierung auf der Getter-Ebene angewendet wurde.

Auch wenn einige andere Eigenschaften meiner Klasse benötigt, um das Alter des Kunden zu ändern, wäre es sinnvoll, die Eigenschaft und nicht das Backing-Feld direkt zu verwenden, da der Setter könnte auch einige Geschäftsregeln Validierungen implementieren, nicht wahr?

Mit anderen Worten, ich sehe wirklich nicht, wie das this-Schlüsselwort die Verwirrung zwischen privaten unterstützenden Mitgliedern und öffentlichen Eigenschaften vermeidet, da dies auf beiden verwendet werden kann und IntelliSense beide zeigt?

Danke.

Antwort

13

Sie haben recht. Es tut es nicht.

Mithilfe von this können Sie sicherstellen, dass Sie das Klassenmitglied bei Namenskonflikten verwenden (sagen Sie einen Parameternamen, der mit einem Feldnamen identisch ist).

Für mich, Pascal Gehäuse öffentliche Mitglieder und Kamel Gehäuse private Mitglieder war schon immer genug von einer Konvention, um gut zu arbeiten.

8

this.age verwenden könnte zwischen dem Sicherungsspeicher Ihrer Age Eigenschaft und ein age Parameter für eine Methode auf dem Objekt helfen zu unterscheiden:

public bool CheckIfOlderThan(int age) 
{ 
    // in here, just using "age" isn't clear - is it the method parameter? 
    // The internal field?? Using this.age make that clear! 
    return (this.age >= age); 
} 

Natürlich in diesem Fall könnten Sie auch Ihre Parameter geben eine weniger verwirrender Name, um irgendwelche Zusammenstöße zu vermeiden ....

Aber in der tatsächlichen Definition der Eigenschaft - seinen Wert im sichernden Speicher lesend und speichernd - fügt die this. nicht wirklich etwas hinzu. Einige Leute, die ich kenne, bevorzugen es einfach, das this. Präfix die ganze Zeit zu benutzen - nicht nur wenn es gebraucht wird - persönliche Vorliebe, wirklich ...

7

Das Voranstellen von privaten Feldern mit Unterstreichung ist im Grunde dasselbe wie die Verwendung von "this.". Allerdings ist Unterstreichung schneller zu verwenden, kürzer und eleganter (das kommt von Java, glaube ich).

Die gleichen Namen für Funktionsparameter und private Felder scheint mir ein bisschen schwierig. Nicht nur einmal habe ich vergessen "dieses" zu verwenden, was zu einer fiesen NullPointerException geführt hat (ja, ich habe irgendwann Java ... :)).

Soweit ich weiß, verletzt es keine FxCop-Regel, da es keine ungarische Notation ist.

+2

Es wird definitiv nicht von Java kommt. In C/C++ - Bezeichnern, die mit Unterstrichen beginnen, ist normalerweise der Compiler reserviert. –

43

Ich ziehe es nachdrücklich die führende „_“ Konvention für private Felder, auch wenn es nicht MS-Konventionen folgen:

  1. Es beseitigt Konflikte mit Kamel Parameternamen verrohrten - keine Notwendigkeit, „diese“

    zu verwenden
  2. Es ist ein visueller Indikator, dass der interne persistente Zustand des Objekts gelesen oder - was noch wichtiger ist - geschrieben wird. Es ist eine Flagge sagen "dies hat Nebenwirkungen außerhalb der bestimmten Methode, die ich zufällig" betrachten, die sehr wichtig ist zu wissen, wenn man auf unbekannten Code.

+11

Ich versuche, die Vorteile der Unterstreichung zu verstehen, aber ich kann einfach sagen: Verwenden Sie 'dies.': 1. Es beseitigt die Notwendigkeit für "_". 2. Es ist ein visueller Indikator, dass der interne persistente Zustand des Objekts ... Sie sehen meinen Standpunkt. Ihr Argument funktioniert in beide Richtungen. – Noich

+8

Es tut tatsächlich. Ein paar mehr Gründe, ich bevorzuge _ über "das" - es ist kompakter, und es ist nicht optional - das Programm wird nicht kompilieren, wenn Sie _ in einer Variablenreferenz vergessen. Aber ich denke, es ist vor allem persönliche Vorliebe ... –

+1

Ad 2: Ist das nicht etwas Syntax Hervorhebung tun sollte? – Jirka

-5

Ich schlage vor, diese Konvention:

class Customer{ 
    private int Age_; 
    public int Age{ 
     get{return Age_;} 
     set{Age_ = value;} 
    } 
    public void MultiplyAge(int age){ 
     Age_ *= age; 
    } 
} 

Die anderen Vorschläge als auch sicherlich eine Überlegung wert sind und die .NET-Richtlinien, die ich gelesen habe, sind in ihren Vorschlägen nicht streng über private Mitglieder zu benennen, sondern ein Unterstrich Hinter ist keine schlechte Wahl aus den folgenden Gründen:

  • ein Hinterstrich (zB Age_), die üblicherweise in C++ für private Felder verwendet wird, da ein Startstrich (zB _Age) w in Konflikt geraten könnte mit dem Compiler. Weitere Informationen finden Sie unter this post. Das ist natürlich nicht wichtig für C#, aber es wäre nett, Konventionen zwischen Sprachen zu beziehen.
  • niedrigere camel case (z. B. Alter) wird am häufigsten in .NET verwendet, um lokale Variablen und Methodenparameter darzustellen.
  • Die Unterscheidung nur basierend auf Groß- und Kleinschreibung (z. B. Alter vs. Alter) reduziert die einfache Portabilität zwischen Sprachen, die sich nicht für Groß-/Kleinschreibung interessieren (wie VB.Net, abhängig von den Konfigurationsoptionen).

Hier ist ein Beispiel dafür, wie ich häufig in einem Szenario enden, wo diese Konvention nützlich für mich war:

class Customer{ 
    private int? Age_; 
    public int Age{get{ 
    if(Age_ == null){ 
     // Really computationally expensive operation for retrieving and setting 
     // Age_ based on results from some external system goes here... or 
     // something like that. 
    } 
    return (int)Age_; 
    }} 
} 
+1

Ich bemerke, dass ich eine Menge Kummer für diese Antwort bekomme. Das ist sicherlich fair, aber können Sie mir sagen, welche Bedenken Sie mit meiner Unterwerfung haben? Ich bin nicht kritisch. Ich bin nur Neugierig. – scradam

+4

Ich würde vermuten, dass es, weil ein Unterstrich am Ende eines Bezeichners ist nicht üblich (ich denke, es ist nicht üblich, weil dies das erste Mal, dass ich es sehe, obwohl ich zugegebenermaßen nicht viel Code.). –