Namenskonvention für private VB.NET-Felder

StackOverflow https://stackoverflow.com/questions/7642

  •  08-06-2019
  •  | 
  •  

Frage

Gibt es eine offizielle Konvention zum Benennen privater Felder in VB.NET?Wenn ich beispielsweise eine Eigenschaft namens „Foo“ habe, nenne ich das private Feld normalerweise „_Foo“.Dies scheint in der EU verpönt zu sein Offizielle Richtlinien:

„Verwenden Sie kein Präfix für Feldnamen.Verwenden Sie beispielsweise nicht g_ oder s_, um zwischen statischen und nicht statischen Feldern zu unterscheiden.“

In C# könnten Sie das private Feld „foo“ und die Eigenschaft „Foo“ nennen und im Konstruktor auf das private Feld als „this.foo“ verweisen.Da VB.NET die Groß-/Kleinschreibung nicht berücksichtigt, ist dies nicht möglich. Haben Sie Vorschläge?

War es hilfreich?

Lösung

Ich verwende in VB immer noch das Präfix _ für private Felder, daher habe ich _foo als privates Feld und Foo als Eigenschaft.Ich mache das auch für C# und so ziemlich jeden Code, den ich schreibe.Im Allgemeinen würde ich mich nicht zu sehr auf die Frage konzentrieren, wie man es richtig macht, weil es nicht wirklich einen „richtigen“ Weg gibt (obwohl es einige sehr schlechte Wege gibt), sondern mich lieber darum kümmern, es konsequent zu tun.

Letztendlich wird Ihr Code durch Konsistenz viel lesbarer und wartbarer, als wenn Sie irgendwelche „richtigen“ Konventionen verwenden.

Andere Tipps

Es ist eine persönliche Präferenz, obwohl es breite Unterstützung dafür gibt manche Unterscheidung.Ich glaube nicht, dass es selbst in C# eine weit verbreitete Konvention gibt.

Jeff Prosise sagt

Aus persönlichen Gründen stelle ich privaten Feldern normalerweise einen Unterstrich voran [in C#] ...Diese Konvention wird im .NET-Framework häufig verwendet, jedoch nicht überall.

Von dem .NET Framework-Designrichtlinien 2. Auflage Seite 73.

Jeffrey Richter sagt

Ich mache alle meine Felder privat und stelle meinen Instanzfeldern „m_“ und meinen statischen Feldern „s_“ voran [in C#]

Von dem .NET Framework-Designrichtlinien 2. Auflage Seite 47.Anthony Moore (BCL-Team) hält auch die Verwendung von „m_“ und „s_“ für eine Überlegung wert, Seite 48.

Offizielle Richtlinien sind genau das – Richtlinien.Man kann sie immer umgehen.Allerdings stellen wir Feldern in der Regel einen Unterstrich voran beide C# und VB.NET.Diese Konvention ist weit verbreitet (und wird von den offiziellen Richtlinien offensichtlich ignoriert).

Auf private Felder kann dann ohne das Schlüsselwort „me“ verwiesen werden (das Schlüsselwort „this“ gilt für C# :)

In den von Ihnen verlinkten Designrichtlinien heißt es ausdrücklich, dass sie nur für statische öffentliche und geschützte Felder gelten.Die Designrichtlinien konzentrieren sich hauptsächlich auf das Design öffentlicher APIs.Was Sie mit Ihren privaten Mitgliedern machen, liegt bei Ihnen.Ich bin mir nicht sicher, bin mir aber relativ sicher, dass private Mitglieder nicht berücksichtigt werden, wenn der Compiler die CLS-Konformität prüft, da dort nur öffentliche/geschützte Mitglieder zum Einsatz kommen (die Idee ist: „Was wäre, wenn jemand, der eine Sprache verwendet, die …“ Erlaubt das Zeichen _ nicht, dass es versucht, Ihre Bibliothek zu verwenden?“ Wenn die Mitglieder privat sind, lautet die Antwort „Nichts, der Benutzer muss diese Mitglieder nicht verwenden.“ Wenn die Mitglieder jedoch öffentlich sind, sind Sie in Schwierigkeiten. )

Dennoch möchte ich den Echoraum erweitern und darauf hinweisen, dass es wichtig ist, bei allem, was Sie tun, konsequent zu sein.Mein Arbeitgeber schreibt vor, dass privaten Feldern sowohl in C# als auch in VB das Präfix _ vorangestellt wird, und da wir alle diese Konvention befolgen, ist es einfach, Code zu verwenden, der von jemand anderem geschrieben wurde.

In VB.NET 4.0 wissen die meisten von Ihnen wahrscheinlich, dass Sie Getter und Setter für Ihre Eigenschaftsdeklarationen nicht explizit wie folgt schreiben müssen:

Public Property Foo As String
Public Property Foo2 As String

VB erstellt automatisch private Mitgliedsvariablen mit den Namen _Foo und _Foo2.Es scheint, als hätten Microsoft und das VS-Team die _-Konvention übernommen, daher sehe ich darin kein Problem.

Ich glaube nicht, dass es eine offizielle Namenskonvention gibt, aber ich habe gesehen, dass Microsoft m_ in der Microsoft.VisualBasic-DLL verwendet (über Reflektor).

Ich benutze das _ Präfix in VB immer noch für private Felder, also habe ich _foo als privates Feld und Foo als Eigenschaft.Ich mache das auch für C# und so ziemlich jeden Code, den ich schreibe.Im Allgemeinen würde ich nicht zu sehr in "Was ist der richtige Weg, um es zu tun" verwickelt, weil es keine "richtige" Weise gibt (obwohl es einige sehr schlechte Wege gibt), sondern sich damit beschäftigt, es konsequent zu tun.

Ich habe nichts Besseres als das „_“ für Klarheit und Konsistenz gefunden.Zu den Nachteilen gehören:

  • Nicht CLS-konform
  • Neigt dazu, verloren zu gehen, wenn VB horizontale Linien über meine IDE zeichnet

Ich umgehe die Zeilen, indem ich sie im Editor ausschalte, und versuche, nicht zu viel über die CLS-Konformität nachzudenken.

Ich stimme @lomaxx zu, es ist wichtiger, im gesamten Team konsistent zu sein, als das zu haben Rechts Konvention.

Dennoch gibt es hier einige gute Orte, an denen Sie Ideen und Anleitungen für Codierungskonventionen erhalten können:

  1. Praktische Richtlinien und Best Practices für Microsoft Visual Basic und Visual C# Developers von Francesco Balena ist ein großartiges Buch, das viele dieser Probleme anspricht.
  2. IDesign-Codierungsstandards (für C# und für WCF)
  3. Das .NET Framework Quellcode (in VS2008)

Ich bevorzuge die Verwendung des Unterstrich-Präfixes für private Felder.Für die Methodenparameter verwende ich den Anfangsbuchstaben in Kleinbuchstaben.Ich folge der Richtlinie, Parameter für Methoden in Kleinbuchstaben zu verwenden, was ich für wichtiger halte als die Benennung privater Felder, da es Teil der API für die Klasse ist..z.B.

Public Class Class1

    Private _foo As String
    Public Property Foo() As String
        Get
            Return _foo
        End Get
        Set(ByVal value As String)
            _foo = value
        End Set
    End Property

    Public Sub New(ByVal foo As String)
        _foo = foo
    End Sub

End Class

Wenn Sie dieses Muster verwenden, treten keine Namenskonflikte mit dem privaten Feld und Ihrem Konstruktorparameter in C# oder VB.NET auf.

Ich stimme zu, dass es nicht am wichtigsten ist, welchen Stil man verwendet, sondern dass er konsistent ist.

Vor diesem Hintergrund lautet der neue MS/.NET-Stil für private Felder tendenziell _fooVar (Unterstrich gefolgt von einem Namen in CamelCased).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top