Warum hat Microsoft Parameter, lokale Variablen und private Felder mit der gleichen Namenskonvention versehen?

18

Ich habe diese Frage vor einiger Zeit gestellt: Wie benennen Sie Ihre privaten Variablen in C #?

In einer der Antworten wurde ich auf die MSDN-Seite von Microsoft verwiesen, die zeigt, dass private Variablen / Felder wie folgt benannt werden sollten:

private int myInteger;

Aber ein Parameter wäre:

void SomeMethod(int myInteger)

und eine lokale Variable wäre wie folgt:

int myInteger;

Also, wenn Sie sie so referenzieren

myInteger = 10;

Sie haben keine Möglichkeit zu wissen, von welchem ​​Sie sprechen.

Ich beginne jetzt ein neues Projekt und einer meiner Mitarbeiter fragt mich, warum wir nicht etwas tun, um zumindest einige davon zu unterscheiden.

Ich frage mich das Gleiche. Warum hat Microsoft diese Standards nicht beibehalten?

Vaccano
quelle
10
Was meinst du mit "du hast keine Möglichkeit zu wissen, von welchem ​​du sprichst"? Natürlich machst du - Umfang.
Thomas Owens
2
Diese Anleitung scheint veraltet zu sein. Die Standardeinstellung für den Resharper (die zu einer Art Defacto-Stilrichtlinie geworden ist) empfiehlt, privaten Feldern einen Unterstrich voranzustellen, wie ich es ohnehin immer getan habe.
25
@kekekela: Es ist absolut nicht veraltet; StyleCop kennzeichnet explizit alle Instanzen von Member-Variablen, die mit einem Unterstrich beginnen. Ehrlich gesagt finde ich den Unterstrich sinnlos und nervig, weil das Gehäuse genau die gleichen Informationen vermittelt. Wenn Sie den Gültigkeitsbereich explizit angeben müssen, setzen Sie die Präfixzuweisung auf this..
Aaronaught
12
@Aaronaught Ich finde ein paar überflüssige "dies". In meinem Code verstreut, sinnlos und irritierend.
12
@kekekela: Der einzige Ort, an dem ich dies jemals tun musste, ist der Konstruktor. Im Konstruktor ist dies absolut sinnvoll, da Sie buchstäblich die Werte übergeben, mit denen die Mitgliedsfelder initialisiert werden ( this.component = component). Wenn Sie sich anderswo mit mehrdeutigen Bereichen konfrontiert sehen, so dass Sie "ein paar überflüssige" dies haben. verstreut um deinen Code ", dann hast du schlecht geschriebenen Code.
Aaronaught

Antworten:

14

Die ursprünglichen Namenskonventionen hatten ein m_-Präfix für Klassenmitglieder, das auf einen einfachen Unterstrich reduziert wurde. Es wird viel älterer C # Microsoft-Code mit einem Unterstrich-Präfix angezeigt. In einem Tech Ed habe ich jedoch einmal gehört, dass ein führender Unterstrich nicht CLS-konform ist. Ich nehme an, dies ist der Grund, warum sie zu dem einfacheren Ein-Namen-für-alle-Schema übergegangen sind. Früher war (noch nicht sicher), dass die Namen von VB.Net, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wurde, auch nicht CLS-konform waren.

Für was es wert ist, verwende ich immer noch den führenden Unterstrich für Klassenmitglieder. Auch wenn Sie mit dieser Option (this.name im Gegensatz zu name) eindeutige Aussagen treffen können, bleiben die Fehler bestehen.

Sie müssen nicht alles tun, was MS Ihnen vorschreibt.

Dave
quelle
1
Ich denke, Sie haben "CLR-konform" mit "CLS-konform" verwechselt. Wenn etwas nicht CLR-konform wäre, würde es nicht kompiliert. CLS ist nur eine Warnung, dass es möglicherweise nicht mit anderen Sprachen kompatibel ist und sich grundsätzlich nur auf öffentliche Mitglieder auswirkt (technisch gesehen, Dinge, die außerhalb Ihrer Assembly sichtbar sind).
Joel C
@Joel - Du hast recht. Diese Frage beschäftigt sich damit: stackoverflow.com/questions/1195030/…
Dave
2
Ich benutze immer noch das Präfix "m_" ...
CesarGon
4
+1 "weil Sie nicht alles tun müssen, was MS Ihnen sagt". Überlegen Sie selbst!
gbjbaanb
1
Es ist nur nicht CLS-konform, wenn das Feld protectednichtprivate
Rachel
9

localund parameterVariablen werden auf dieselbe Weise benannt, da ihr Gültigkeitsbereich identisch ist

In Bezug auf private Variablen gibt es unterschiedliche Meinungen dazu. Ich habe immer die hier gefundenen Standards verwendet , die die Verwendung von führenden _vor privaten Variablen vorgeben , obwohl der Autor sagt, dass das _etwas umstritten ist und Microsoft dagegen empfiehlt.

Wikipedia gibt das in C und C ++ an

Namen, die mit einem doppelten Unterstrich oder einem Unterstrich und einem Großbuchstaben beginnen, sind für die Implementierung reserviert (Compiler, Standardbibliothek) und sollten nicht verwendet werden (z. B. __reserved oder _Reserved).

Vielleicht war dies der Grund, warum Microsoft dies empfahl, obwohl es allgemein bekannt ist, dass viele Microsoft-Entwickler sowieso ein _Präfix für ihre privaten Variablen verwenden.

Rachel
quelle
2
Ein guter Punkt zu Parametern und lokalen Variablen mit demselben Gültigkeitsbereich (+1). Niemand sonst erwähnte das. Die Folge ist, dass Sie, wenn Sie eine lokale Variable mit demselben Namen wie der Parameter benötigen, einfach den Parameter verwenden können. Persönlich finde ich Unterstrich hässlich und ungenau. Wobei sich thisdefinitiv auf das aktuelle Objekt bezieht. Ich verstehe den Hass nicht this. Liegt es daran, dass es missverstanden wird?
Jason S
4

Ich kann dir nicht genau sagen, warum sie nicht anders waren. Es ist wahrscheinlich, dass niemand dies kann, wenn nicht jemand, der an der Erstellung der Standards beteiligt war, diese Frage sieht.

Viele Leute erstellen ihre eigenen Konventionen, indem sie Instanzvariablen mit _oder voranstellen m_, aber ich glaube wirklich nicht, dass es darauf ankommt. Sie können viel aus dem Kontext schließen, und IDEs sind heutzutage klug genug, um Ihnen zu helfen. In Visual Studio mit dem ReSharper-Addon werden beispielsweise lokale Variablen und Instanzvariablen in verschiedenen Farben angezeigt.

Wenn es wirklich darauf ankommt, dass Sie zwischen den beiden Bereichen unterscheiden, können Sie das this.Präfix verwenden, um auf die Instanzvariable zu verweisen:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Ohne weitere Plugins hilft Ihnen Visual Studio standardmäßig mit Intellisense:

Bildschirmfoto

(Das Popup wird dort möglicherweise noch von ReSharper gestaltet, aber ReSharper fügt den Funktionen von integriertem Intellisense nichts hinzu. Während das Standard-Popup also ein wenig anders aussieht, hat es immer noch beide Optionen. )

Sie können auch Code-Analyse-Tools wie FxCop und StyleCop verwenden , um potenzielle Probleme mit der Benennung und dem Gültigkeitsbereich von Variablen zu erkennen.

Adam Lear
quelle
thisIch bevorzuge thises immer , ein bisschen näher darauf einzugehen , denn es bezieht sich definitiv auf die aktuelle Instanz, egal in welchem ​​Haus Sie sich befinden, also ist es genau. Die m-Konventionen mit oder ohne Unterstrich sind genau das - Konventionen, die auf Instanzvariablen verweisen können oder nicht, und die von redundant gemacht werden this. Der einzige Punkt, den ich als nützlich erachte, ist VB, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird, um Objekt- und Klassennamen zu unterscheiden. Aber das ist eine ganz andere Geschichte.
Jason S
4

Warum hat Microsoft diese Standards nicht beibehalten?

Die Leute von Microsoft haben ein Buch mit dem Titel Framework Design Guidelines geschrieben dem eine Reihe von Konventionen erläutert wurden, darunter, warum einige Dinge in Kamelschalen und andere in Pascalschalen verpackt waren .

Bearbeiten (Hinzufügen von Details aus dem Buch):

In dem Buch erwähnen sie das Durchführen von Usability-Studien sowie einige der Lehren aus dem Erwerb der Turbo Pascal-Gruppe. Auch wenn nicht alle Sprachen zwischen Groß- und Kleinschreibung unterscheiden (wie z. B. VB), sollten andere Sprachen (wie z. B. C #) bei der Benennung konsistent sein. Man kann sich nicht allein auf Unterschiede verlassen, um Gegenstände zu unterscheiden. Wenn man sich an die Konventionen hält, die im Rest des Frameworks verwendet werden, führt dies zu weniger Verwirrung bei den Entwicklern.

Kapitel 3, Namensrichtlinien.
Abschnitt 3.1 befasst sich mit Kapitalisierungskonventionen.

camelCasingist für Parameternamen.
PascalCasingsteht für Namespace-, Typ- und Mitgliedsnamen. Wenn der Name Akronyme mit zwei Buchstaben enthält, lassen Sie diese in Großbuchstaben, z IOStream.

Abschnitt 3.5 behandelt die Benennung von Klassen, Strukturen und Schnittstellen.
Abschnitt 3.6 behandelt die Benennung von Typenmitgliedern.
Abschnitt 3.7 behandelt die Namensparameter.

Tangurena
quelle
4
Möchten Sie für diejenigen von uns zusammenfassen, die das Buch nicht besitzen?
Kramii setzt Monica
Ich stimme Kramii zu. Eine Zusammenfassung wäre toll!
Vaccano
@Kramil, Vaccano, es sieht so aus, als müsste ich es noch einmal aus der Bibliothek auschecken. Normalerweise mache ich das nur, wenn ich einen neuen Job beginne und Diskussionen über Benennungs- und Kodierungsstandards führen.
Tangurena
1
lol, also "Man kann sich nicht allein auf Unterschiede verlassen, um Gegenstände zu unterscheiden", dann benutze camelCase oder PascalCase, um Gegenstände zu unterscheiden.
Gbjbaanb
1

Weil sie ziemlich unterscheidbar sind, da sie vom Kontext abhängen, in dem sie geschrieben sind.

Haben Sie zum Beispiel jemals einen Parameter als Elementvariable verwendet? Oder eine lokale Variable als Parameter? Wie wäre es mit einer Mitgliedsvariablen als lokale?

  • Alle Member-Variablen befinden sich im "Body" einer Klasse. Ich kaufe wirklich nicht das Argument, dass Sie dem Member ein Präfix voranstellen müssen, wenn Sie es thiszur Unterscheidung von einer lokalen Variablen mit einem ähnlichen Namen verwenden können, sonst wird es nicht benötigt.

  • Eine lokale Variable wird auch nur innerhalb eines Methodenbereichs oder eines Codeblockbereichs definiert.

  • In der Methodensignatur ist immer ein Parameter definiert.

Wenn Sie all diese Arten von Variablen durcheinander bringen oder vermischen, sollten Sie sich mehr Gedanken über Ihr Code-Design machen, um es lesbarer oder auffindbarer zu machen. Geben Sie ihnen bessere und aussagekräftigere Namen als myInteger.

Spoike
quelle
0

Ich kann Ihre Frage zu den Standards von Microsoft nicht beantworten. Wenn Sie ein Standard wollen , diese Dinge zu unterscheiden, die Standard - I Verwendung für PL / SQL - Parameter wird prefixing die Parameternamen mit in_, out_, io_, für die Innen-, out- und in-out- Parameter. Variablen, die für eine Funktion lokal sind, wird ein vorangestelltes v_.

FrustratedWithFormsDesigner
quelle
0

Die meisten mir bekannten Unternehmen haben Codierungsstandards, die entweder einen Unterstrich oder den Kleinbuchstaben m (für "Mitglied", nehme ich an) als Präfix für ihre Mitgliedsvariablen angeben.

So

_varName

oder

mVarName

ElGringoGrande
quelle
2
Ja, aber MS missbilligen die Verwendung des m für Mitglieder, worauf das OP hinausläuft.
Christopher Bibbs
"Die meisten Unternehmen" schließen Microsoft nicht ein, um welches Unternehmen es sich bei dieser Frage handelt.
Aaronaught
1
Mir war nicht klar, dass Microsoft MSDN für interne Codierungsstandards bei Microsoft vorgesehen ist.
JeffO
1
@JeffO: Sie haben recht, aber die internen Kodierungsrichtlinien sagen dasselbe aus .
Aaronaught
0

Genau wie andere darauf hingewiesen haben, können Sie in der Regel anhand des Umfangs, in dem der Artikel verwendet wird, erkennen, welcher Gegenstand welcher ist. Sie können den Parameter und die lokale Variable nicht im selben Bereich haben. Wenn Sie die private Variable möchten, verwenden Sie einfach this.myInteger. Microsoft hat sich also meiner Meinung nach keine allzu großen Sorgen gemacht, da Sie leicht zwischen ihnen unterscheiden können, wenn Sie dies möchten.

Trotzdem bin ich ein bisschen überrascht, dass dies noch niemand gesagt hat, aber vergessen Sie Microsoft und seine Namenskonventionen (nun, vielleicht hat es schon jemand gesagt, da ich zu einer Besprechung laufen musste und dies offen ließ, ohne es einzureichen) es). Die ungarische Notation war auch eine Namenskonvention, die bei Microsoft eingeführt wurde (oder war es Xerox? Ich kann mich nie erinnern, wann Simonyi sie erfunden hat). Ich kann mir niemanden vorstellen, von dem ich weiß, dass er den Namen der ungarischen Notation bis heute nicht verflucht. Wir haben uns so darüber geärgert, dass ich gearbeitet habe, dass wir uns einen eigenen Standard ausgedacht haben, den wir intern verwendet haben. Das machte für uns mehr Sinn und beschleunigte unsere Arbeit ein wenig (es war eigentlich ziemlich nahe an dem, was Microsoft jetzt vorschlägt, aber mit Ausnahme von privaten Variablen war alles pascal case).

Allerdings ist der neuere Standard, den Microsoft verwendet (die Mischung aus Camel Case und Pascal Case), nicht allzu schlecht. Aber wenn es Ihnen und Ihren Mitarbeitern nicht gefällt, entwickeln Sie Ihre eigenen Standards (am besten kollektiv). Dies hängt natürlich davon ab, ob Ihr Unternehmen bereits über eine Reihe von Standards verfügt. Wenn doch, bleib bei ihnen. Ansonsten überlegen Sie sich, was für Sie und Ihre Mitarbeiter funktioniert. Halte es einfach logisch. '

Da bat Aaronaught um ein Zitat über Charles Simonyi und die ungarische Notation: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Die letzten beiden sind nur Beispiele für die ungarische Notation, und der Link ootips enthält nur einige Zitate zu einigen Meinungen zu diesem Thema. Beachten Sie, dass es auch die ungarische Systemnotation gibt, die meines Wissens aber auch bei Microsoft-Programmierern an Beliebtheit gewonnen hat (obwohl ich im Gegensatz zu Simonyi für die App-Variante nicht weiß, wen).

JaCraig
quelle
1
1) Ungarisch wurde nicht von Microsoft erfunden, und 2) das "Ungarisch", auf das Sie sich beziehen, ist eher Typungarisch als semantisches Ungarisch.
Aaronaught
Ich habe nie gesagt, dass Microsoft darauf gekommen ist. Ich sagte tatsächlich, Charles Simonyi habe es erfunden (speziell Apps in ungarischer Notation). Microsoft hat es stark vorangetrieben, aber ich habe nie gesagt, dass sie es erstellt haben. Ich habe es als ein Beispiel für etwas angeführt, das eine große Firma (Microsoft) als die Art und Weise vorgeschlagen hat, wie Dinge getan werden sollten. Mein Punkt dabei ist, dass sich das OP keine Gedanken über Namenskonventionen machen sollte, die ein Unternehmen, für das er nicht arbeitet, für den "richtigen Weg" hält (es sei denn, er arbeitet für Microsoft, in diesem Fall sollte er sich darum kümmern).
JaCraig
[Zitat benötigt]
Aaronaught
1
Wir brauchten kein Zitat darüber, was ungarische Notation ist. Das [Zitat benötigt] ist für alle zweifelhaften Behauptungen in Ihrer Antwort.
Aaronaught