Welche Art von Präfix tun für Sie Membervariablen verwenden?

https://stackoverflow.com/questions/111605

02-07-2019
|

Frage

Kein Zweifel, es ist wichtig für das Verständnis Code Membervariablen einen Präfix zu geben, so dass sie leicht von „normalen“ Variablen unterschieden werden können.

Aber welche Art von Präfix verwenden Sie?

Ich habe an Projekten gearbeitet, wo haben wir m _ als Präfix, auf andere Projekte, die wir nur einen Unterstrich verwendet (was ich persönlich nicht mag, weil ein Unterstrich nicht nur demonstrative ist genug).

Auf einem anderen Projekt haben wir eine lange Präfix Form, die auch den Variablentyp enthalten. mul _ Beispiel ist das Präfix einer M ember Variable vom Typ u nsigned l Ong.

Nun lassen Sie mich wissen, welche Art von Präfix verwenden Sie (und bitte einen Grund dafür geben).

EDIT: Die meisten von Ihnen scheinen ohne spezielle Präfixe für Membervariablen zu codieren! Hängt dies von der Sprache? Aus meiner Erfahrung, C ++ Code neigt einen Unterstrich oder m _ als Präfix für Membervariablen zu verwenden. Was ist mit anderen Sprachen?

Lösung

Kein Zweifel, es ist wichtig für das Verständnis Code Membervariablen einen Präfix zu geben, so dass sie leicht von „normalen“ Variablen unterschieden werden können.

ich bestreiten diesen Anspruch. Es ist nicht das geringste notwendig, wenn Sie halbwegs anständige Syntax-Hervorhebung haben. Eine gute IDE können Sie Ihren Code in lesbarem Englisch schreiben, und können Ihnen die Art und den Umfang ein Symbol anderen Weise zeigen. Eclipse hat eine gute Arbeit durch Erklärungen und Verwendungen eines Symbols hervorgehoben, wenn der Einfügemarke auf einem von ihnen ist.

Bearbeiten dank schlank: Eine gute Syntax-Highlighter wie Eclipse wird auch Sie fett oder kursiv Text verwenden oder Schriftarten ganz ändern. Zum Beispiel mag ich Kursivschrift für statische Dinge.

Ein weiterer edit: Denken Sie daran, auf diese Weise; Art und Umfang einer Variablen sind sekundäre Informationen. Es sollte an Sie herausfinden, aber nicht schrie verfügbar und einfach sein. Wenn Sie Präfixe wie m_ oder Typen wie LPCSTR verwenden, das wird Lärm, wenn Sie nur die primären Informationen lesen mögen -. Die Absicht des Code

Dritter bearbeiten. Dies gilt unabhängig von der Sprache

Andere Tipps

ich jeden Präfix gar nicht verwenden. Wenn ich in Gefahr laufen Sie mit den Teilnehmern lokale Variablen oder Methodenparameter der Vermischung, dann entweder das Verfahren oder die Klasse ist zu lang und profitiert von Aufspaltung .

Das (wohl) macht nicht nur der Code besser lesbar und etwas „fließend“, aber am wichtigsten ist fördert gut strukturierte Klassen und Methoden . Am Ende läuft es somit zu einem ganz anderen Problem nach unten als das Präfix oder No-Präfix dillema.

UPDATE: gut, Geschmack und Vorlieben ändern, oder nicht .. ich jetzt Strich als Präfix für Membervariablen verwenden, wie es bei der Erkennung lokale und Membervariablen auf langer Sicht als vorteilhaft erwiesen hat. Vor allem neue Teammitglieder manchmal schwer haben, wenn die beiden nicht leicht zu erkennen.

Keine. Ich verwendete Strich zu verwenden, wurde aber aus ihm an einem Projekt gesprochen, wo die anderen es nicht mochte, und haben es nicht verpassen. Eine anständige IDE oder ein anständiger Speicher wird Ihnen sagen, was ist eine Membervariable und was nicht. Einer der Entwickler auf unserem Projekt besteht auf Putting „dies.“ vor jedem Mitgliedsvariable, und wir Humor ihn, wenn wir uns auf Bereiche des Codes arbeiten, die nominell „sein“.

sind

Unders nur.

In meinem Fall, ich benutze es, weil das ist, was das Coding-Standards Dokument an meinem Arbeitsplatz sagt. Allerdings kann ich nicht den Punkt m_ oder eine schreckliche ungarische Sache am Anfang der Variablen hinzuzufügen. Die minimalistische ‚unterstreichen nur‘ hält es lesbar ist.

Es ist wichtiger als alles andere, konsequent zu sein, so wählen Sie etwas, das Sie und Ihre Mitspieler einigen können und bleiben Sie dabei. Und wenn die Sprache, die Sie bei der Codierung sind eine Konvention hat, sollten Sie versuchen, es zu bleiben. Nichts ist mehr verwirrend als eine Codebasis, die inkonsistent eine Vorfixierung Regel folgt.

c ++, gibt es einen anderen Grund m_ über bevorzugen _ neben der Tatsache, dass _ manchmal Compiler Schlüsselwörter Präfixe. Das M steht für Elementvariable. Dies gibt Ihnen auch die Möglichkeit, Disambiguieren zwischen Einheimischen und den anderen Klassen von Variablen, s_ für statische und g_ für die globale (aber natürlich nicht Globals verwenden).

Wie für die Kommentare, dass die IDE immer um Sie kümmern wird, ist die IDE wirklich der einzige Weg, die Sie in Ihrem Code suchen? Hat Ihr Diff-Tool das gleiche Maß an Qualität für Syntax hilighting als IDE hat? Was ist mit Ihrer Quellcodeverwaltung Revisionshistorie-Tool? Haben Sie noch nie eine Quelldatei in der Befehlszeile Katze? Moderne IDE sind fantastische Effizienz-Tools, aber Code sollte einfach sein, unabhängig vom Kontext zu lesen, werden Sie es in zu lesen.

Ich ziehe this Schlüsselwort. Das bedeutet this.data oder this->data anstatt einige Community-abhängige Namensgebung.

Denn:

mit heutzutage IDEs eingeben this. Popups intellinsense
sein für jeden offensichtlich ohne definierte Namensgebung zu wissen,

BTW Variablen mit Buchstaben prefixing ihre Art zu bezeichnen, ist mit guten IDEs veraltet und erinnert mich an dieser Joels Artikel

Wir verwenden m_ und dann eine etwas Simonyi Notation verändert, genauso wie Rob sagt, in einer früheren Antwort. Also, Vorfixierung scheint nützlich und m_ ist nicht zu aufdringlich und leicht durchsucht auf.

Warum Notation überhaupt? Und warum nicht einfach folgen (für .NET) die Schreibweise Empfehlungen Microsoft, die von Namen auf Gehäuse verlassen?

letzte Frage zuerst: Wie erwähnt, VB.NET ist gleichgültig Gehäuse. So sind Datenbanken und (vor allem) DBAs. Als ich gerade customerID und CustomerID halten müssen (in, sagen wir, C #), macht es mein Gehirn verletzt. So Gehäuse ist eine Form der Notation, aber nicht sehr effektiv ein.

Präfixnotation hat einen Wert in mehrfacher Hinsicht:

Erhöht das menschliche Verständnis von Code, ohne die IDE. Wie in Code-Review -., Die ich immer noch am einfachsten zunächst auf dem Papier zu tun
haupt schreiben T-SQL oder andere RDBMS gespeichert Procs? Präfixnotation verwendet auf Datenbank Spaltennamen ist sehr hilfreich, vor allem für diejenigen von uns, die Text-Editoren wie für diese Art von Sachen.

kurz Vielleicht prefixing als eine Form der Notation nützlich ist, weil es noch Entwicklungsumgebungen, wo Smart IDEs nicht verfügbar sind. Denken Sie an die IDE (ein Software-Tool), wie uns einige Abkürzungen erlaubt (wie Intellisense Typisierung), aber nicht die gesamte Entwicklungsumgebung umfasst.

Eine IDE ist eine integrierte Entwicklungsumgebung in der gleichen Weise, dass ein Auto ein Transportnetz ist: nur ein Teil eines größeren Systems. Ich will nicht einer „Auto“ Konvention wie ein Aufenthalt auf markierte Straßen, folgen, wenn manchmal, sein schneller nur durch eine Baulücke zu gehen. Unter Berufung auf dem IDE variable Eingabe zu verfolgen wäre wie das Auto GPS, um durch die Baulücke zu gehen. Besser haben das Wissen (peinlich, obwohl es sein kann „m_intCustomerID“ zu haben) in einer tragbaren Form als zurück zum Auto für jeden kleinen Kurswechsel ausgeführt werden.

Das heißt, die m_ Konvention oder die „this“ Konvention sind beide lesbar. Wir möchten m_, weil es leicht gesucht und immer noch erlaubt die variable Eingabe ihn zu folgen. Vereinbart, dass ein einfacher Strich durch zu viele andere Framework-Code-Aktivitäten verwendet wird.

C #, habe ich aus dem bewegten ‚m _'- Präfix nur einen Unterstrich , da 'm_' ist ein Erbe von C ++ .

Die offizielle Microsoft-Richtlinien erfahren Sie keine Präfixe zu verwenden und zu Verwendung Kamel-Fall auf private Mitglieder und pascal-Fall auf öffentlichen Mitglieder . Das Problem ist, dass dies kollidiert mit einer anderen Richtlinie aus der gleichen Quelle, die besagt, dass sollten Sie alle Codes kompatibel mit allen Sprachen in .NET verwendet werden. Zum Beispiel hat VB.NET keinen Unterschied zwischen Gehäuse machen.

Also nur ein Unterstrich für mich. Dies macht es auch einfach durch IntelliSense zugreifen und externen Code nur öffentliche Mitglieder aufrufen müssen nicht die visuell unordentlich Unterstrichen sehen.

Update: Ich glaube nicht, das C # "auswählen." - prefix hilft aus der "Ich". in VB, die noch werden "Me.age" das gleiche wie "Me.Age" sehen.

Es hängt davon ab, welchen Rahmen verwende ich! Wenn ich MFC-Code ich schreibe dann verwende ich m _ und ungarische Notation. Für andere Sachen (die STL / Boost neigt), dann füge ich einen Unter Suffix für alle Membervariablen und ich nicht mit ungarischer Notation stören.

MFC-Klasse

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

STL-Klasse

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

Nun, das mag ein wenig seltsam erscheinen - zwei verschiedene Arten -. Aber es funktioniert für mich, und eine Menge von MFC-Code zu schreiben, die nicht den gleichen Stil nicht verwendet wie MFC selbst nur hässlich aussieht

I Präfix Elementvariablen mit 'm' und die Parameter (in der Funktion) mit 'P'. So wird Code wie folgt aussehen:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

Ich finde, dass dies sagt Ihnen, schnell den Grundumfang einer Variablen - wenn kein Präfix, dann ist es eine lokale. Auch wenn eine Funktion Lesen Sie nicht brauchen, um darüber nachzudenken, was in übergeben wird ist, und was ist nur eine lokale Variable.

Es hängt wirklich von der Sprache. Ich bin ein C ++ Typ, und mit Unterstrich alles prefixing ist ein bisschen schwierig. Die Sprache Reserven Sachen, die für die Umsetzung in einigen Fällen (je nach Umfang) mit Unterstrich beginnt. Es gibt auch spezielle Behandlung für Doppelstrich oder durch einen Großbuchstaben folgende Strich. Also sage ich nur vermeiden, dass Chaos und einfach einen anderen Präfix wählen. 'M' ist IMO ok. ‚M_‘ ist ein wenig zu viel, aber auch nicht schrecklich. Eine Frage des Geschmacks wirklich.

Aber achten Sie auf die _leadingUnderscores. Sie werden überrascht sein, wie viele Compiler und Bibliothek Interna so genannt werden, und es gibt definitiv Raum für Unfälle und mixup, wenn Sie nicht sehr vorsichtig sind. Nur nein sagen.

Die meiste Zeit verwende ich Python. Python erfordert, dass Sie self.foo verwenden, um das Attribut foo der Instanz der aktuellen Klasse zuzugreifen. Auf diese Weise wird das Problem der verwirrenden lokalen Variablen, Parameter und Attribute der Instanz, die Sie auf Arbeit ist gelöst.
Im Allgemeinen mag ich diesen Ansatz, auch wenn ich gezwungen Abneigung ist, es zu tun. So meine ideale Weise thos zu tun ist, es nicht zu tun und eine Form von Attribute Zugriff auf diese oder mich selbst um die Elementvariablen zu holen zu verwenden. Auf diese Weise, ich habe nicht mit Meta-Daten, die Namen Krempel.

Wenn die Sprache unterstützt die dieses oder Me Schlüsselwort, verwenden Sie keinen Präfix und stattdessen die Verwendung Schlüsselwort.

Ein weiterer Trick ist Namenskonvention :

Alle Membervariablen wie üblich genannt werden, ohne Präfix (oder ‚das.‘ Ist es üblich, so in dem Projekt zu tun)

Aber sie werden leicht, weil in meinem Projekt von lokalen Variablen zu unterscheiden, werden diese lokalen Variablen immer genannt:

a Something:. Für ein Objekt
einig manythings:. Liste der Objekte
ist Astate oder hat Something:. Für boolean Zustand

Jede Variable, die durch 'a' beginnt nicht, 'einige' oder 'ist ihr /' ist eine Membervariable.

Da VB.NET nicht case-sensitive ist das Präfix ich meine Membervariablen mit einem Unterstrich und Kamel Fall den Rest des Namens. Ich kapitalisieren Eigenschaftsnamen.

Dim _valueName As Integer

Public Property ValueName() As Integer

Ich bin mit den Leuten, die Präfixe nicht verwenden.

IDEs heutzutage so gut sind, ist es einfach, die Informationen über eine Variable auf einem Blick aus Syntaxfärbung, Mouse-Over-Tooltips und einfacher Navigation zu seiner Definition zu finden.

Dies ist oben auf, was Sie aus dem Kontext der variablen und Namenskonventionen erhalten können (wie lowerCamelCase für lokale Variablen und private Felder, Uppercamelcase für Eigenschaften und Methoden usw.) und Dinge wie „hasXXXX“ und „ISXX“ für booleans.

Ich habe keine Präfixe seit Jahren verwendet, aber ich verwendet habe eine als „das.“ Präfix Monster, aber ich habe gegangen, dass, wenn es unbedingt notwendig ist (danke, ReSharper).

Ich bin Weirdo und ich Präfix Membervariablen mit Initialen aus dem Klassennamen (das Kamel verrohrten).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

Die meisten der Delphi Menschen nur F verwenden.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

Ein einzelner _ nur als visueller Indikator verwendet. (C #)

hilft die Gruppenmitglieder mit Intellisense.
einfacher, die Elementvariablen zu erkennen, wenn Sie den Code zu lesen.
schwieriger, eine Membervariable mit einer lokalen Definition zu verbergen.

`_` statt `this.`

Ich benutze _ auch statt this. weil nur kürzer ( 4 Zeichen weniger), und es ist ein guter Indikator für Membervariablen. Außerdem diesen Präfix verwenden, können Sie Namenskonflikte vermeiden. Beispiel:

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

Vergleichen Sie es mit diesem:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

Ich finde das erste Beispiel kürzer und klarer.

Es hängt ein bisschen, welche Sprache Sie arbeiten in.

In C # können Sie jedes Mitglied Referenz mit dem ‚dieses‘ prefix, z.B. ‚This.val‘, was bedeutet, werden keine Präfixe erforderlich. VB hat eine ähnliche Fähigkeit mit 'Me'.

In Sprachen, wo es eine eingebaute in Notation zur Anzeige Zugangselement Ich sehe nicht den Punkt in einen Präfix verwenden. In anderen Sprachen, ich denke, es sinnvoll zu verwenden, was die allgemein akzeptierte Konvention für diese Sprache macht, ist.

Beachten Sie, dass einer der Vorteile eine integrierte in Notation ist, dass Sie es auch verwenden können, wenn die Eigenschaften und Methoden auf der Klasse zugreifen, ohne Ihre Namenskonventionen für diejenigen zu gefährden (das ist besonders wichtig, wenn nicht-private Mitglieder Zugriff) . Der Hauptgrund für jede Art von Indikatoren ist als ein Flag, das Sie mögliche Nebenwirkungen in der Klasse verursachen, so ist es eine gute Idee, es zu haben, wenn andere Mitglieder verwenden, unabhängig davon, ob sie ein Feld / Eigenschaft / Methode / etc .

Ich benutze Kamel Fall und unterstreichen, wie viele hier. Ich benutze den Unterstrich, weil ich mit C # arbeiten, und ich habe auf die Verhinderung des ‚this‘ Schlüsselwort in meiner Konstrukteurs gewöhnt. I Kamel Fall Methode-scoped Varianten, so dass die Unterstreichungs mich daran erinnern, welche Möglichkeiten ich arbeite zur Zeit mit an. Ansonsten glaube ich nicht, dass es so lange zählt, wie Sie nicht hinzufügen unnötige Informationen versuchen, die bereits im Code ersichtlich ist.

ich verwendet habe, m_ Präfix in C ++, aber in C # zu verwenden, ziehe ich es nur Kamel Fall für das Feld und pascal Fall für seine Eigenschaft.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Ich mag m_ aber solange Konvention in der Code-Basis verwendet wird, wird verwendet, ich bin cool mit ihm.

Ihr mul_ Beispiel wird in Richtung Charles Simonyi Apps ungarische Notation.

Ich ziehe Dinge einfach zu halten und deshalb habe ich als Präfix mag mit m_.

Dadurch macht es viel einfacher zu sehen, wo Sie die ursprüngliche Erklärung gehen, um zu sehen.

neige ich m_ in C ++ zu verwenden, würde aber nichts dagegen weg # in Java oder C zu verlassen. Und es hängt von dem Codierungsstandard. Für Legacy-Code, der eine Mischung aus Strich hat und m_ würde ich den Code auf einen Standard-Refactoring (eine vernünftige Codegröße angegeben)

Ich verwende @.

: D j / k - aber wenn nicht die Art von der Sprache abhängig. Wenn es Getter / Setter hat, werde ich in der Regel eine setzen _ vor dem private Variable und die Getter / Setter den gleichen Namen haben, ohne die _. Ansonsten habe ich verwende in der Regel nicht.

Für meine eigenen Projekte I _ als Postfix verwenden (wie Martin Yorkeren oben erwähnt, _ als Präfix ist reserver durch den C / C ++ Standard für die Compiler-Implementierungen) und i bei der Arbeit auf Symbian Projekte .

In Java, eine gemeinsame Konvention ist Mitglied Variablen Vorwort mit "my" andUseCamelCaseForTheRestOfTheVariableName.

Keine, wenn es nicht notwendig, einzelner Strich anders. Gilt für Python.

Wenn es wirklich notwendig ist, Membervariablen Präfix, würde ich auf jeden Fall m_ lieber nur einen Unterstrich. Ich finde, ein Unterstrich auf eigene Lesbarkeit reduziert und kann mit C ++ reservierte Wörter verwechselt werden.

Aber ich bezweifle, dass die Mitgliedsvariablen eine spezielle Notation benötigen. Auch IDE Hilfe zu ignorieren, ist es nicht offensichtlich ist, warum es Verwirrung wäre zwischen dem, was einem lokalen ist und was eine Membervariable.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow

Welche Art von Präfix tun für Sie Membervariablen verwenden?

_ statt this.

`_` statt `this.`