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

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?

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.

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.

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:

(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.

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.

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.

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_.

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

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).