Unterstreichen oder nicht unterstreichen, das ist die Frage

Gibt es Probleme, privaten Feldern keinen Unterstrich in C # voranzustellen, wenn die Binärversion von anderen Framework-Sprachen verwendet werden soll? Da bei C # beispielsweise zwischen Groß- und Kleinschreibung unterschieden wird, können Sie ein Feld "foo" und die öffentliche Eigenschaft "Foo" aufrufen, und es funktioniert einwandfrei.

Hätte dies irgendeine Auswirkung auf Groß- und Kleinschreibung Sprache wie VB.NET, wird es durch eine CLS-Compliance (oder andere) Probleme , wenn die Namen nur unterscheidbar sind durch Gehäuse?

Es wird keine Wirkung haben.

Ein Teil der Empfehlungen zum Schreiben von CLS-kompatiblen Bibliotheken besteht darin, NICHT zwei öffentliche / geschützte Entitäten zu haben, die sich nur von Fall zu Fall unterscheiden, z. B. sollten Sie NICHT haben

public void foo() {...}

und

public void Foo() {...}

Was Sie beschreiben, ist kein Problem, da das private Element dem Benutzer der Bibliothek nicht zur Verfügung steht

WICHTIGES UPDATE (12. April 2016):

Wir wurden darauf aufmerksam gemacht, dass der interne Standard des .NET CoreFX-Teams darauf besteht, die Unterstrich-Notation zu verwenden, ohne Aufschluss darüber zu geben, warum. Aber wenn wir genau an der Regel 3 # aussehen wird es offensichtlich , dass es ein System _, t_, s_Präfixe, warum schlägt vor , _in erster Linie gewählt.

3. Wir verwenden _camelCasefür interne und private Felder und verwenden diese nach Möglichkeit schreibgeschützt. Präfix Instanzfelder mit _, statische Felder mit s_und Thread statische Felder mit t_. Bei Verwendung auf statischen Feldern readonlysollte nach kommen static(dh static readonlynicht readonly static).
4. Wir vermeiden, es this.sei denn, dies ist unbedingt erforderlich.

Also , wenn Sie wie .NET CoreFX Team arbeitet an einem gewissen Leistung kritisch, multithreaded, Systemebene Code , dann ist es dringend empfohlen , dass Sie:

• halten sich an ihre Kodierungsstandards und
• Verwenden Sie die Unterstrich-Notation und
• Lies diese Antwort nicht weiter

Ansonsten lesen Sie bitte weiter ...

DIE URSPRÜNGLICHE ANTWORT:

Lassen Sie uns zunächst vereinbaren, worüber wir sprechen. Die Frage ist, wie wir aus nicht statischen Methoden und Konstruktoren einer Klasse / Unterklasse auf Instanzmitglieder zugreifen, wenn Sichtbarkeitsmodifikatoren dies zulassen.

Unterstreichungsnotation

• schlägt vor, dass Sie das Präfix "_" in den Namen privater Felder verwenden
• Es heißt auch, dass Sie "dies" niemals verwenden sollten, es sei denn, dies ist absolut notwendig

Diese Notation

• schlägt vor, dass Sie einfach immer "dies" verwenden. um auf ein Instanzmitglied zuzugreifen

Warum existiert diese Notation?

Weil du so bist

• Unterscheiden Sie einen Parameter von einem Feld, wenn sie denselben Namen haben
• Stellen Sie sicher, dass Sie im Kontext der aktuellen Instanz arbeiten

Beispiel

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Warum existiert die Unterstrich-Notation?

Einige Leute mögen es nicht, "dies" einzugeben, aber sie brauchen immer noch eine Möglichkeit, ein Feld und einen Parameter zu unterscheiden. Deshalb haben sie sich bereit erklärt, "_" vor einem Feld zu verwenden

Beispiel

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

Man könnte denken, es ist nur eine Frage des persönlichen Geschmacks und beide Wege sind gleich gut / schlecht. Es gibt jedoch bestimmte Aspekte, bei denen diese Notation die Unterstrichnotation übertrifft:

Klarheit

• Unterstrich-Notation überladen Namen
• Diese Notation hält die Namen intakt

Kognitive Belastung

• Die Unterstrich-Notation ist inkonsistent. Sie behandelt Felder auf besondere Weise, kann sie jedoch nicht jedes Mal mit anderen Mitgliedern verwenden, wenn Sie sich fragen müssen, ob Sie eine Eigenschaft oder ein Feld benötigen

• Diese Notation ist konsistent, Sie müssen nicht denken, Sie verwenden einfach immer "dies", um auf ein Mitglied zu verweisen

UPDATE: Wie bereits erwähnt, ist das Folgende kein Vorteilspunkt

Instandhaltung

• Bei der Unterstrichnotation müssen Sie _beim Refactoring ein Auge darauf haben , z. B. ein Feld in eine Eigenschaft verwandeln (entfernen _) oder das Gegenteil (hinzufügen _).

• Diese Notation hat kein solches Problem

Autovervollständigung

Wenn Sie die Liste der Instanzmitglieder anzeigen müssen:

• Die Unterstrich-Notation hilft Ihnen nicht viel, denn wenn Sie "_" eingeben, zeigt das Popup für die automatische Vervollständigung die privaten Felder und alle Typen an, die in den verknüpften Assemblys verfügbar sind, gemischt mit den übrigen Instanzmitgliedern
• Diese Notation gibt Ihnen eine klare Antwort, indem Sie "dies" eingeben. Alles, was Sie sehen, ist die Liste der Mitglieder und sonst nichts

Mehrdeutigkeit

Manchmal muss man mit dem Code ohne Hilfe des Intellisense umgehen. Zum Beispiel, wenn Sie Codeüberprüfungen durchführen oder den Quellcode online durchsuchen.

• Die Unterstrich-Notation ist nicht eindeutig: Wenn Sie Something.SomethingElse sehen, können Sie nicht sagen, ob Something eine Klasse und SomethingElse ihre statische Eigenschaft ist ... oder vielleicht ist Something eine aktuelle Instanzeigenschaft, die ihre eigene Eigenschaft von SomethingElse hat

• Diese Notation ist klar: Wenn Sie Something.SomethingElse sehen, kann dies nur eine Klasse mit einer statischen Eigenschaft bedeuten, und wenn Sie diese sehen.Something.SomethingElse wissen Sie, dass Something ein Mitglied ist und SomethingElse seine Eigenschaft

Erweiterungsmethoden

Sie können keine Erweiterungsmethoden für die Instanz selbst verwenden, ohne "this" zu verwenden.

• Die Unterstrich-Notation erfordert, dass Sie "dies" nicht verwenden, jedoch mit den Erweiterungsmethoden, die Sie benötigen
• Diese Notation erspart Ihnen das Zögern. Sie verwenden immer "this", Punkt.

Visual Studio-Unterstützung

• Die Unterstrich-Notation bietet in Visual Studio keine integrierte Unterstützung

• Diese Notation wird von Visual Studio natürlich unterstützt:

  1. "Dies." Qualifikation : Bevorzugen Sie, dass alle nicht statischen Felder, die in nicht statischen Methoden verwendet werden, this.in C # vorangestellt werden

Offizielle Empfehlungen

Es gibt viele offizielle Richtlinien, die eindeutig sagen "Verwenden Sie keine Unterstriche", insbesondere in C #

• Die Unterstrich-Notation stammt aus C ++, wo es eine allgemeine Praxis ist, um Namenskonflikte zu vermeiden. Außerdem wird VisualBasic.Net empfohlen, ein Problem zu lösen, bei dem ein Feld "Wert" und eine Eigenschaft "Wert" tatsächlich denselben Namen haben, da VisualBasic unterscheidet nicht zwischen Groß- und Kleinschreibung

  1. Deklarierte Elementnamen in Visual Basic
  2. Sichern von Feldern in VisualBasic.NET

• Diese Notation wird für C # empfohlen, während "_" ausdrücklich verboten ist:

  1. dieses Schlüsselwort in C #
  2. Feldnutzungsrichtlinien : Do ein Präfix Feldnamen oder statische Feldnamen keine Anwendung.
  3. Richtlinien für Namen: Namen von Typmitgliedern : Verwenden Sie kein Präfix für Feldnamen.
  4. Allgemeine Namenskonvention : X Verwenden Sie KEINE Unterstriche, Bindestriche oder andere nicht alphanumerische Zeichen
  5. Qualitätssicherungsregel CA1707 : Bezeichner sollten keine Unterstriche enthalten
  6. Die Verwendung von Unterstrichen ist nicht CLS-konform (für öffentliche und geschützte Bezeichner).
  7. Interne Namenskonvention von .NET Framework-Entwicklern : Verwenden Sie kein Präfix für Mitgliedsvariablen. Wenn Sie zwischen lokalen und Mitgliedsvariablen unterscheiden möchten, sollten Sie "this" verwenden. in C # und "Ich". in VB.NET.

Entnommen aus der Microsoft StyleCop-Hilfedatei:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Ursache: Ein Feldname in C # beginnt mit einem Unterstrich.

Regelbeschreibung:

Ein Verstoß gegen diese Regel tritt auf, wenn ein Feldname mit einem Unterstrich beginnt.

Standardmäßig verbietet StyleCop die Verwendung von Unterstrichen, m_ usw., um lokale Klassenfelder zugunsten des 'this' zu markieren. Präfix. Der Vorteil von 'this'. ist, dass es für alle Elementtypen einschließlich Methoden, Eigenschaften usw. und nicht nur für Felder gleichermaßen gilt, sodass alle Aufrufe von Klassenmitgliedern sofort erkennbar sind, unabhängig davon, welcher Editor zum Anzeigen des Codes verwendet wird. Ein weiterer Vorteil besteht darin, dass eine schnelle, erkennbare Unterscheidung zwischen Instanzmitgliedern und statischen Mitgliedern erstellt wird, denen kein Präfix vorangestellt wird.

Wenn der Feld- oder Variablenname mit dem Namen eines mit Win32 oder COM verknüpften Elements übereinstimmen soll und daher mit einem Unterstrich beginnen muss, platzieren Sie das Feld oder die Variable in einer speziellen NativeMethods-Klasse. Eine NativeMethods-Klasse ist eine Klasse, die einen Namen enthält, der auf NativeMethods endet, und als Platzhalter für Win32- oder COM-Wrapper gedacht ist. StyleCop ignoriert diese Verletzung, wenn das Element in einer NativeMethods-Klasse platziert wird.

Eine andere Regelbeschreibung gibt an, dass die bevorzugte Vorgehensweise zusätzlich zu den oben genannten darin besteht, private Felder mit Kleinbuchstaben und öffentliche mit Großbuchstaben zu beginnen.

Bearbeiten: Im Anschluss daran befindet sich die Projektseite von StyleCop hier: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . Das Lesen der Hilfedatei gibt einen guten Einblick, warum verschiedene Stilregeln vorgeschlagen werden.

Da es sich um ein privates Feld handelt, hat dies keine Auswirkungen auf einen Benutzer Ihrer Klasse.

Ich empfehle jedoch, einen Unterstrich für das private Feld zu verwenden, da dies das Verständnis des Codes erleichtern kann, z.

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

In unserem Team verwenden wir immer ein Unterstrichpräfix für private Felder. Wenn ich also Code lese, kann ich sehr leicht private Felder identifizieren und sie von Einheimischen und Argumenten unterscheiden. In gewisser Weise kann der Unterstrich als Kurzfassung von "dies" angesehen werden.

Nachdem ich in einer Umgebung gearbeitet hatte, die seitdem sehr spezifische und sehr sinnlose Stilregeln hatte, kreierte ich meinen eigenen Stil. Dies ist ein Typ, den ich viel hin und her gedreht habe. Ich habe schließlich entschieden, dass private Felder immer _field sein werden, lokale Variablen niemals _ und Kleinbuchstaben sein werden, Variablennamen für Steuerelemente lose der ungarischen Notation folgen und Parameter im Allgemeinen camelCase sein werden.

Ich hasse das this.Schlüsselwort, es fügt meiner Meinung nach einfach zu viel Code-Rauschen hinzu. Ich liebe Resharper's überflüssige Entfernung. Stichwort.

6-Jahres-Update: Ich habe die Interna von Dictionary<TKey,T>auf eine bestimmte Verwendung des gleichzeitigen Zugriffs analysiert und ein privates Feld als lokale Variable falsch interpretiert. Private Felder sollten definitiv nicht die gleiche Namenskonvention wie lokale Variablen haben. Wenn es einen Unterstrich gegeben hätte, wäre das unglaublich offensichtlich gewesen.

Ich mag den Unterstrich, weil ich dann den Kleinbuchstaben als Methodenparameter wie diesen verwenden kann:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

Ich mag es immer noch sehr, Unterstriche vor privaten Feldern zu verwenden, aus dem Grund, den Martin erwähnt hat, und auch, weil private Felder dann in IntelliSense zusammen sortiert werden. Dies trotz der Bösartigkeit der ungarischen Präfixnotationen im Allgemeinen.

In letzter Zeit stelle ich jedoch fest, dass die Verwendung des Unterstrichpräfixes für private Mitglieder verpönt ist, obwohl ich nicht ganz sicher bin, warum. Vielleicht weiß es jemand anderes? Ist es nur das Präfixprinzip? Oder gab es etwas mit der Namensverfälschung von generischen Typen zu tun, die in kompilierten Assemblys oder so etwas unterstrichen werden?

Style Cop-Empfehlung oder nicht, das Eingraben in .NET Framework zeigt eine Menge "_" -Verwendung für Mitgliedsvariablen. Was auch immer die Entwickler von Style Cop empfehlen, es ist nicht das, was die Mehrheit der MS-Mitarbeiter verwendet. :) Also bleibe ich beim Unterstrich. Da ich persönlich mit dem Unterstrich viel weniger Fehler mache als mit dem (Beispiel: Wenn ich varName = varName anstelle von this.varName = varName verwende, steckt es wirklich in mir)

Ich denke, dass Felder auf Klassenebene im Großen und Ganzen ein Fehler bei der Gestaltung der Sprache sind. Ich hätte es vorgezogen, wenn die Eigenschaften von C # einen eigenen lokalen Bereich hätten:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Das würde es möglich machen, die Verwendung von Feldern vollständig einzustellen.

Das einzige Mal, dass ich einem privaten Feld einen Unterstrich voranstelle, ist, wenn für eine Eigenschaft ein separates Hintergrundfeld erforderlich ist. Dies ist auch das einzige Mal, dass ich private Felder benutze . (Und da ich niemals geschützte, interne oder öffentliche Felder verwende, ist dies das einzige Mal, dass ich Feldperioden verwende.) Wenn eine Variable einen Klassenbereich haben muss, ist sie für mich eine Eigenschaft der Klasse.

Die _fieldName-Notation für private Felder ist so einfach zu brechen . Verwenden von "this". Notation ist unmöglich zu brechen. Wie würden Sie die Notation brechen? Beobachten:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

Ich habe gerade gegen Ihre Namenskonvention verstoßen, aber sie wird kompiliert. Ich würde es vorziehen, eine Namenskonvention zu haben, die a) nicht ungarisch und b) explizit ist. Ich bin dafür, die ungarische Namensgebung abzuschaffen, und dies qualifiziert in gewisser Weise. Anstelle des Objekttyps vor dem Variablennamen haben Sie dessen Zugriffsebene.

Vergleichen Sie dies mit Ruby, wo der Name der Variablen @my_numberden Namen in den Bereich einbindet und unzerbrechlich ist.

edit: Diese Antwort ist negativ geworden. Es ist mir egal, es bleibt.

Wenn Ihre Assembly CLS-kompatibel sein soll, können Sie das CLSCompliant-Attribut in Ihrer Assemblyinfo-Datei verwenden. Der Compiler wird sich dann beschweren, wenn Ihr Code Dinge enthält, die nicht cls-konform sind.

Wenn Sie dann zwei Eigenschaften haben, die sich nur in diesem Fall unterscheiden, gibt der Compiler einen Fehler aus. Wenn Sie jedoch ein privates Feld und ein öffentliches Eigentum in derselben Klasse haben, gibt es keine Probleme.

(Aber ich stelle meinen privaten Mitgliedern auch immer einen Unterstrich voran. Es hilft mir auch, beim Lesen meines Codes klar zu machen, dass eine bestimmte Variable ein Mitgliedsfeld ist.)

Ich verwende aus zwei Gründen gerne Unterstriche vor meinen privaten Feldern. Eines wurde bereits erwähnt, die Felder heben sich im Code und in Intellisense von den zugehörigen Eigenschaften ab. Der zweite Grund ist, dass ich dieselben Namenskonventionen verwenden kann, unabhängig davon, ob ich in VB oder C # codiere.

Es gibt keinerlei Auswirkungen. Wenn Ihr Code kompiliert wird, ist für den Compiler nur der Namespace und die Sichtbarkeit des Felds / der Eigenschaft wichtig. Ein Unterstrich ist bei der Benennung eines Bezeichners genauso wichtig wie jedes andere Zeichen. Der eigentliche Trick besteht darin, eine Konvention zu verwenden, die Sie und die Menschen um Sie herum verstehen werden.