it-swarm.com.de

Namenskonvention - Unterstrich in C++ - und C # -Variablen

Es ist üblich, einen _var-Variablennamen in einem Klassenfeld anzuzeigen. Was bedeutet der Unterstrich? Gibt es eine Referenz für all diese speziellen Namenskonventionen?

121
Stan

Der Unterstrich ist einfach eine Konvention; nichts mehr. Daher unterscheidet sich seine Verwendung von Person zu Person. So verstehe ich sie für die beiden fraglichen Sprachen:

In C++ gibt ein Unterstrich normalerweise eine private Membervariable an.

In C # sehe ich normalerweise, dass es nur verwendet wird, wenn die zugrunde liegende private Mitgliedsvariable für eine öffentliche Eigenschaft definiert wird. Andere private Member-Variablen hätten keinen Unterstrich. Diese Verwendung ist jedoch mit dem Aufkommen automatischer Eigenschaften weitgehend auf der Strecke geblieben.

Vor:

private string _name;
public string Name
{
    get { return this._name; }
    set { this._name = value; }
}

Nach dem:

public string Name { get; set; }
100
jdmichal

Bitte verwenden Sie NICHT UNDERSCORES vor einem Variablennamen oder Parameternamen in C++ !!!

Namen, die mit einem Unterstrich oder einem doppelten Unterstrich beginnen, werden für die C++ - Implementierer RESERVIERT. Namen mit einem Unterstrich sind für die Arbeit der Bibliothek reserviert.

Wenn Sie im C++ - Coding-Standard gelesen haben, werden Sie auf der ersten Seite Folgendes sehen:

"Benennen Sie die Benennung nicht zu hoch, sondern verwenden Sie eine konsistente Benennungskonvention: Es gibt nur zwei wichtige Punkte: a) Verwenden Sie niemals" unbenutzte Namen ", die mit einem Unterstrich beginnen oder einen doppelten Unterstrich enthalten. (p2, C++ - Codierungsstandards, Herb Sutter und Andrei Alexandrescu)

Sie können auch selbst sehen, warum die Verwendung von Unterstrichen bei der Entwicklung einer Software katastrophal sein kann.

Versuchen Sie, ein einfaches helloWorld.cpp-Programm wie folgt zu kompilieren:

g++ -E helloWorld.cpp

Sie werden alles im Hintergrund sehen. Hier ist ein Ausschnitt:

   ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
   try
     {
       __streambuf_type* __sb = this->rdbuf();
       if (__sb)
  {
    if (__sb->pubsync() == -1)
      __err |= ios_base::badbit;
    else
      __ret = 0;
  }

Sie können sehen, wie viele Namen mit doppeltem Unterstrich beginnen!

Wenn Sie sich virtuelle Elementfunktionen anschauen, werden Sie feststellen, dass * _vptr der Zeiger für die virtuelle Tabelle ist, die automatisch erstellt wird, wenn Sie eine oder mehrere virtuelle Elementfunktionen in Ihrer Klasse verwenden! Aber das ist eine andere Geschichte ...

Wenn Sie Unterstriche verwenden, kann es zu Konflikten kommen und Sie werden keine IDEA was verursacht es, bis es zu spät ist.

59

Tatsächlich stammt die _var-Konvention von VB und nicht von C # oder C++ (m _, ... ist eine andere Sache).

Dies beseitigte die Unempfindlichkeit von VB bei der Deklaration von Proprieties

beispielsweise ist ein solcher Code in VB nicht möglich, da er user und User als denselben Bezeichner betrachtet

Private user As String

Public Property User As String
  Get
    Return user
  End Get
  Set(ByVal Value As String)
    user = value
  End Set
End Property

Um dies zu überwinden, verwendeten einige eine Konvention, um '_' zum privaten Feld hinzuzufügen, um so zu kommen

Private _user As String

Public Property User As String
  Get
    Return _user
  End Get
  Set(ByVal Value As String)
    _user = value
  End Set
End Property

Da viele Konventionen für .Net gelten und eine gewisse Einheitlichkeit zwischen den Konventionen für C # und VB.NET bestehen, verwenden sie dieselbe.

Ich fand die Referenz für das, was ich sagte: http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

Kamelhülle mit führendem Unterstrich. Im VB.NET, immer "Protected" oder .__ angeben. "Privat", verwenden Sie nicht "Dim". Gebrauch von "m_" wird entmutigt, ebenso wie die Verwendung eines Variablenname, der sich von der .__ unterscheidet. Eigenschaft von nur Fall, besonders mit geschützte Variablen, da dies verletzt Compliance und wird Ihr Leben zu einem Schmerzen, wenn Sie in VB.NET programmieren, wie Sie müsste Ihre Mitglieder benennen etwas anderes als Eigenschaften von Accessor/Mutator. Von allen die Elemente hier, der führende Unterstrich ist wirklich der einzige umstrittene . Ich persönlich bevorzuge es gerade unterstrichenloses Kameletui für meine private Variablen, so dass ich nicht um Variablennamen mit "this" zu qualifizieren zur Unterscheidung von Parametern in Konstruktoren oder anderswo, wo ich wird wahrscheinlich eine Namenskollision haben . Mit der Groß- und Kleinschreibung von VB.NET ist dies ist noch wichtiger als dein Accessor-Eigenschaften haben normalerweise derselbe Name wie Ihr privates Mitglied Variablen mit Ausnahme des Unterstrichs . Was m_ betrifft, ist es wirklich nur über Ästhetik. Ich (und viele andere) Finde m_ hässlich, wie es dort aussieht ist ein Loch im Variablennamen. Es ist fast beleidigend. Ich habe es in .__ verwendet. VB6 die ganze Zeit, aber das war nur weil Variablen kein .__ haben konnten. führender Unterstrich. Ich könnte es nicht sein. glücklicher zu sehen, wie es weggeht. Microsoft empfiehlt gegen das m_ (und das gerade _), obwohl beide in ihrem Code. Außerdem wird ein .__ vorangestellt. gerade "m" ist gleich raus. Na sicher, Da sie hauptsächlich in C # codieren, können sie haben private Mitglieder, die sich nur unterscheiden für den Fall von den Eigenschaften. VB Leute muss etwas anderes machen Eher, als versuchen Sie es mit sprachspezifische Sonderfälle, ich empfehlen den führenden Unterstrich für alle Sprachen, die es unterstützen. Ob Ich möchte, dass meine Klasse voll ist CLS-konform, ich könnte das .__ weglassen. Präfix für jedes C # -geschützte Member Variablen. In der Praxis jedoch habe ich Sorgen Sie sich nie darum, da ich alle möglicherweise geschützte Elementvariablen privat und Versorgung geschützt stattdessen Accessoren und Mutatoren. Warum: Kurz gesagt, ist diese Konvention einfach (ein Zeichen), leicht lesbar (Ihr Auge wird nicht durch andere Hauptfiguren abgelenkt) und erfolgreich vermeidet Namenskollisionen mit Variablen auf Prozedurebene und Eigenschaften auf Klassenebene. Eigenschaften auf Klassenebene.

40
Zied

Der erste Kommentar (R Samuel Klatchko) verwies auf: Wie lauten die Regeln für die Verwendung eines Unterstrichs in einem C++ - Bezeichner? das beantwortet die Frage nach dem Unterstrich in C++. Im Allgemeinen sollten Sie keinen führenden Unterstrich verwenden, da dieser für den Implementierer Ihres Compilers reserviert ist. Der Code, den Sie mit _var sehen, ist wahrscheinlich entweder ein älterer Code oder ein Code, der von jemandem geschrieben wurde, der mit dem alten Benennungssystem aufwuchs, das bei den führenden Unterstrichen keine Stirn runzelte. 

Als anderer Antwortstatus wurde er in C++ verwendet, um Klassenmitgliedervariablen zu identifizieren. Es hat jedoch keine besondere Bedeutung, was Dekorateure oder Syntax angeht. Wenn Sie es also verwenden möchten, wird es kompiliert.

Ich werde die C # -Diskussion anderen überlassen.

5
bsruth

_var hat keine Bedeutung und dient nur dazu, die Unterscheidung, dass die Variable eine private Membervariable ist, zu erleichtern.

In C++ ist die Verwendung der _var-Konvention eine schlechte Form, da für die Verwendung des Unterstrichs vor einem Bezeichner Regeln gelten. _var ist als globale Kennung reserviert, während _Var (Unterstrich + Großbuchstabe) jederzeit reserviert ist. Aus diesem Grund werden in C++ Leute angezeigt, die stattdessen die var_-Konvention verwenden.

4
5ound

Sie können Ihre eigenen Codierrichtlinien erstellen. Schreiben Sie einfach eine klare Dokumentation für den Rest des Teams.

Die Verwendung von _field hilft dem Intelilsense, alle Klassenvariablen zu filtern, die einfach _ eingeben.

Ich befolge normalerweise die Brad Adams-Richtlinien , aber es wird empfohlen, keinen Unterstrich zu verwenden.

4

Der Microsoft-Benennungsstandard für C # besagt, dass Variablen und Parameter die untere Kamelform IE verwenden sollten:paramName. Der Standard fordert auch, dass Felder demselben Format folgen. Dies kann jedoch zu unklarem Code führen. Daher fordern viele Teams einen Unterstrich als Präfix, um die Übersichtlichkeit IE zu verbessern:_fieldName

2
ChaosPandion

Bei Verwendung von C # schlagen Microsoft Framework Design Guidelines vor, den Unterstrich für public -Mitglieder nicht zu verwenden. Für private -Mitglieder können Unterstriche verwendet werden. Tatsächlich verwendet Jeffrey Richter (in den Richtlinien häufig zitiert) beispielsweise ein m_ und ein "s_" für private statische Mitglieder. 

Persönlich benutze ich nur _, um meine privaten Mitglieder zu kennzeichnen. "m_" und "s_" schließen sich an die ungarische Notation an, die in .NET nicht nur verpönt ist, sondern auch sehr ausführlich sein kann. Ich finde Klassen mit vielen Mitgliedern schwierig, einen schnellen Augenscan alphabetisch durchzuführen (stellen Sie sich 10 Variablen vor, die alle mit m_ beginnen) .

2
P.Brian.Mackey

Ich benutze die _var-Benennung für Membervariablen meiner Klassen. Dafür gibt es zwei Hauptgründe:

1) Es hilft mir, Klassenvariablen und lokale Funktionsvariablen zu verfolgen, wenn ich später meinen Code lese.

2) Es hilft in Intellisense (oder einem anderen Code-Vervollständigungssystem), wenn ich nach einer Klassenvariablen suche. Nur das erste Zeichen zu kennen, ist hilfreich beim Filtern der Liste der verfügbaren Variablen und Methoden.

1
A.J.

Für die Sprachen C und C++ hat der Name (Anfang, Mitte oder Ende) keine besondere Bedeutung für einen Unterstrich. Es ist nur ein gültiges Variablennamenzeichen. Die "Konventionen" stammen von Kodierungspraktiken innerhalb einer Kodierungsgemeinschaft.

Wie bereits durch verschiedene Beispiele oben angedeutet, kann _ am Anfang private oder geschützte Mitglieder einer Klasse in C++ bedeuten.

Lassen Sie mich nur etwas Geschichte erzählen, die unterhaltsam sein kann. Wenn Sie unter UNIX über eine Core-C-Bibliotheksfunktion und ein Kernel-Back-End verfügen, in dem Sie die Kernel-Funktion für den Benutzerbereich freigeben möchten, bleibt _ vor dem Funktionsstub, der die Kernel-Funktion direkt aufruft, ohne etwas anderes zu tun. Das bekannteste und bekannteste Beispiel dafür ist exit () vs _exit () unter BSD- und SysV-Typ-Kernel: Dort erledigt exit () den User-Space-Bereich, bevor er den Exit-Service des Kernels aufruft, während _exit nur dem Exit-Service des Kernels zugeordnet wird.

Also wurde _ für "lokales" Zeug in diesem Fall verwendet, dass lokal maschinenlokal ist. Normalerweise waren _functions () nicht portabel. Dabei sollten Sie auf verschiedenen Plattformen nicht dasselbe Verhalten erwarten.

Nun wie bei _ in Variablennamen wie 

int _foo; 

Nun, psychologisch gesehen ist ein _ eine seltsame Sache, die man am Anfang eingeben muss. Wenn Sie also einen Variablennamen erstellen möchten, der eine geringere Wahrscheinlichkeit für einen Konflikt mit etwas anderem hätte, sollten Sie bei der Verwendung von Pre-Prozessor-Ersetzungen die Verwendung von _ in Betracht ziehen.

Mein grundlegender Rat wäre, immer die Konventionen Ihrer Programmiergemeinschaft zu befolgen, damit Sie effektiver zusammenarbeiten können.

1
Elf King

Es gibt einen durchaus legitimen Grund, es in C # zu verwenden: wenn der Code auch von VB.NET erweiterbar sein muss.

Da bei VB.NET die Groß- und Kleinschreibung nicht berücksichtigt wird, gibt es keine einfache Möglichkeit, auf den geschützten Member field in diesem Code zuzugreifen:

public class CSharpClass
{
    protected int field;
    public int Field { get { return field; } }
}

Z.B. Dadurch wird auf den Eigenschafts-Getter zugegriffen, nicht auf das Feld:

Public Class VBClass
    Inherits CSharpClass

    Function Test() As Integer
        Return Field
    End Function

End Class

Ich kann nicht mal field in Kleinbuchstaben schreiben - VS 2010 korrigiert es nur.

Um abgeleiteten Klassen in VB.NET leicht zugänglich zu sein, muss eine andere Namenskonvention erstellt werden. Das Voranstellen eines Unterstrichs ist wahrscheinlich das am wenigsten aufdringliche und "historisch" akzeptierte.

0
Andras Vass

Es gibt keine bestimmte Namenskonvention, aber ich habe das für private Mitglieder gesehen.

0
Cade Roux

Nach meiner Erfahrung (sicherlich begrenzt) zeigt ein Unterstrich an, dass es sich um eine private Member-Variable handelt. Wie Gollum sagte, wird dies jedoch vom Team abhängen.

0
Smashery

Viele Leute bevorzugen private Felder, denen ein Unterstrich vorangestellt ist. Es ist nur eine Namenskonvention.

Die offiziellen Namenskonventionen von C # schreiben für private Felder einfache Kleinbuchstaben (kein Unterstrich) vor.

Ich kenne keine Standardkonventionen für C++, obwohl Unterstriche häufig verwendet werden.

0
Mau

Es ist nur eine Konvention, die einige Programmierer verwenden, um es klar zu machen, wenn Sie ein Element der Klasse oder eine andere Art von Variablen (Parameter, lokal für die Funktion usw.) bearbeiten. Eine andere Konvention, die auch für Member-Variablen weit verbreitet ist, setzt dem Namen 'm_' voran.

Jedenfalls sind dies nur Konventionen und Sie werden nicht für alle eine einzige Quelle finden. Sie sind eine Frage des Stils und jedes Programmierteam, Projekt oder Unternehmen hat seinen eigenen (oder gar keinen).

0
goedson

Die Notation, die "this" wie in this.foobarbaz verwendet, ist jetzt für C # -Klassenmitgliedervariablen akzeptabel. Es ersetzt die alte "m_" - oder "__" -Notation. Dadurch wird der Code lesbarer, da es keinen Zweifel gibt, worauf Bezug genommen wird.

0
ddm