it-swarm.com.de

Ungarische Notation in C #

Vor der Verwendung von C # war C++ meine primäre Programmiersprache. Und die ungarische Schreibweise ist tief in meinem Herzen.

Ich habe einige kleine Projekte in C # gemacht, ohne ein C # -Buch oder andere Richtlinien zu lesen. In diesen kleinen C # -Projekten habe ich so etwas verwendet 

private string m_strExePath;

Bis ich etwas von SO las, das sagte:

Verwenden Sie keine ungarische Schreibweise.

Warum also? Bin ich die einzige Person, die m_strExePath oder m_iNumber in meinem C # -Code hat?

32
Jason

Joel Spolsky hat einen wirklich guten Artikel zu diesem Thema. Die kurze Zusammenfassung ist, dass es zwei Arten der ungarischen Schreibweise gibt, die in der Praxis verwendet werden. 

Der erste ist "Systems Hungarian", wo Sie den Variablentyp mit einem Präfix angeben. Dinge wie "str" ​​für string. Dies ist nahezu nutzlos, zumal moderne IDEs Ihnen den Typ sowieso mitteilen. 

Das zweite ist "Apps Hungarian", wo Sie den Zweck der Variablen mit einem Präfix angeben. Das gebräuchlichste Beispiel hierfür ist die Verwendung von "m_" zur Anzeige von Member-Variablen. Dies kann sehr nützlich sein, wenn es richtig gemacht wird.

Meine Empfehlung wäre, "Systems Hungarian" wie die Pest zu vermeiden, aber "Apps Hungarian" auf jeden Fall zu verwenden, wo es sinnvoll ist. Ich schlage vor, Joels Artikel zu lesen. Es ist etwas langatmig, erklärt es aber viel besser als ich könnte.

Der interessanteste Teil dieses Artikels ist, dass der ursprüngliche Erfinder der ungarischen Notation, Charles Simonyi, "Apps Hungarian" erstellt hat, aber sein Artikel wurde furchtbar falsch interpretiert und der Gräuel von "Systems Hungarian" wurde als Ergebnis geschaffen.

48
17 of 26

Beim Entwerfen der Benutzeroberfläche habe ich es sehr nützlich gefunden, die ungarische Schreibweise zu pflegen. Elemente wie Textfelder, Beschriftungen und Dropdown-Listen sind viel einfacher zu verstehen und oft erhalten Sie wiederkehrende Kontrollnamen:

lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList

Für mich ist das einfacher zu lesen und zu analysieren. Ansonsten passt die ungarische Notation aufgrund der Fortschritte bei IDEs, insbesondere bei Visual Studio, nicht.

Joel on Software hat auch einen hervorragenden Artikel zur ungarischen Notation mit dem Titel: Falschen Code falsch aussehen der einige gute Argumente liefert für Ungarische Notation.

31
Gavin Miller

Sie sind nicht die einzige Person, aber ich würde sagen, es ist relativ ungewöhnlich. Ich persönlich bin kein Fan von ungarischer Notation, zumindest nicht in dem einfachen Sinn, der lediglich die Typinformationen wiedergibt, die bereits in der Deklaration enthalten sind. (Fans von "wahrer" ungarischer Notation erklären den Unterschied - es hat mich nie so sehr gestört, aber ich kann ihren Standpunkt erkennen. Wenn Sie ein gemeinsames Präfix für Einheiten von Länge und Gewichtseinheiten verwenden, werden Sie nicht versehentlich eine Längenvariable mit einem Gewichtswert zuweisen, auch wenn beide Ganzzahlen sein können.)

Für private Mitglieder können Sie jedoch tun, was Sie wollen - Sie können mit Ihrem Team die Namenskonvention vereinbaren. Der wichtige Punkt ist, dass, wenn Sie möchten, dass IhreAPIzum Rest von .NET passt, keine ungarische Notation in Ihren öffentlichen Mitgliedern (einschließlich Parametern) verwenden.

29
Jon Skeet

Nein, du bist nicht der einzige, der es tut. Es wird allgemein angenommen, dass die ungarische Notation nicht der beste Weg ist, um Dinge in C # zu benennen (die IDE behandelt eine Menge der Probleme, mit denen die ungarische Notation versucht hat).

21
Justin Niessner

Die ungarische Schreibweise ist ein schrecklicher Fehler in der Sprache " any ". Sie sollten es auch nicht in C++ verwenden. Benennen Sie Ihre Variablen, damit Sie wissen, wozu sie dienen. Benennen Sie sie nicht, um die Typinformationen zu duplizieren, die Ihnen IDE ohnehin geben kann und die sich ändern können (und ist normalerweise ohnehin irrelevant. Wenn Sie wissen, dass etwas ein Zähler ist, ist es egal, ob Es ist ein Int16, 32 oder 64. Sie wissen, dass es als Zähler fungiert, und daher sollte jede Operation, die für einen Zähler gültig ist, gültig sein. Dasselbe Argument für X/Y-Koordinaten. Sie sind Koordinaten. Es spielt keine Rolle ob es sich um Floats oder Doubles handelt. Es kann relevant sein, zu wissen, ob ein Wert in Gewicht, Distanz oder Geschwindigkeit angegeben wird. Es ist nicht wichtig, dass es sich um einen Float handelt.

Tatsächlich kam die ungarische Notation nur als Missverständnis vor. Der Erfinder hatte beabsichtigt, damit den "konzeptuellen" Typ einer Variablen zu beschreiben (ist es eine Koordinate, ein Index, ein Zähler, ein Fenster?)

Und die Leute, die seine Beschreibung gelesen hatten, nahmen an, dass er mit "Typ" den tatsächlichen Programmiersprachentyp meinte (int, float, nullterminierte Zeichenfolge, Zeichenzeiger).

Das war nie die Absicht und es ist eine schreckliche Idee. Es kopiert Informationen, die die IDE besser bereitstellen kann, und die überhaupt nicht relevant sind, da sie dazu anregen, auf der niedrigstmöglichen Abstraktionsebene zu programmieren. 

Warum also? Bin ich die einzige Person, die m_strExePath oder m_iNumber in meinem C # Code hat?

Nein, leider nicht. Sag mir, was wäre exePath, wenn es nicht ein String wäre? Warum muss ich als Leser Ihres Codes wissen, dass es sich um eine Zeichenfolge handelt? Ist es nicht genug zu wissen, dass es sich um den Pfad zur ausführbaren Datei handelt? m_iNumber hat nur einen schlechten Namen. welche nummer ist das? Wofür ist das? Sie haben mir gerade zweimal gesagt, dass es sich um eine Zahl handelt, aber ich weiß immer noch nicht, was die Zahl bedeutet.

12
jalf

Sie sind sicherlich nicht die einzige Person, aber ich hoffe, dass Sie Teil eines abnehmenden Trends sind :)

Das Problem der ungarischen Schreibweise besteht darin, dass versucht wird, ein Typsystem über Namenskonventionen zu implementieren. Dies ist äußerst problematisch, da es sich um ein Typensystem handelt, das nur von Menschen überprüft wird. Jeder Mensch im Projekt muss denselben Standards zustimmen, strenge Codeüberprüfungen durchführen und sicherstellen, dass allen neuen Typen das richtige und korrekte Präfix zugewiesen wird. Kurz gesagt, es ist unmöglich, die Konsistenz mit einer ausreichend großen Codebasis zu gewährleisten. An diesem Punkt gibt es keine Konsequenz, warum machst du es?

Außerdem unterstützen Werkzeuge keine ungarische Schreibweise. Das mag wie ein dummer Kommentar auf der Oberfläche erscheinen, z. B. das Refactoring. Jedes Refactoring in einem ungarischen Namenskonventionssystem muss mit einer Massenumbenennung einhergehen, um sicherzustellen, dass die Präfixe beibehalten werden. Massenumbenennungen sind anfällig für alle Arten von subtilen Fehlern. 

Anstatt Namen zur Implementierung eines Typsystems zu verwenden, verlassen Sie sich einfach auf das Typsystem. Es verfügt über eine automatische Überprüfung und Tool-Unterstützung. Neuere IDEs erleichtern das Erkennen eines Variablentyps (Intellisense, Hover-Tipps usw.) und lassen den ursprünglichen Wunsch nach ungarischer Notation wirklich verschwinden. 

10
JaredPar

Ein Nachteil der ungarischen Schreibweise ist, dass Entwickler den Typ der Variablen während des frühen Codierens häufig ändern, wodurch auch der Name der Variablen geändert werden muss.

6
Patrick Peters

wenn Sie nicht einen Texteditor anstelle des VS IDE verwenden, ist die ungarische Schreibweise von geringem Wert, und die Lesbarkeit wird dadurch eher eingeschränkt als verbessert

5
kloucks

Der tatsächliche Wert der ungarischen Schreibweise geht auf die C-Programmierung und die schwach typisierte Art von Zeigern zurück. Grundsätzlich war es am einfachsten, den Typ über Ungarisch zu verfolgen.

In Sprachen wie C # sagt Ihnen das Typsystem alles, was Sie wissen müssen, und das IDE zeigt Ihnen dies auf sehr benutzerfreundliche Weise, so dass Sie einfach kein Ungarisch verwenden müssen.

Aus gutem Grund, es nicht zu verwenden, gibt es einige. Zunächst einmal, in C # und natürlich auch in C++ und vielen anderen Sprachen, da Sie oft Ihre eigenen Typen erstellen. Was wäre also der Ungarisch für einen "MyAccountObject" -Typ? Selbst wenn Sie sich für sinnvolle ungarische Schreibweisen entscheiden können, wird der Name der Variablen etwas schwerer lesbar, da Sie am Anfang "LPZCSTR" (oder was auch immer) überspringen müssen. Wichtiger sind jedoch die Wartungskosten. Was passiert, wenn Sie mit einer Liste beginnen und zu einer anderen Sammlungsart wechseln (etwas, das ich im Moment viel zu tun habe)? Sie müssen dann alle Ihre Variablen umbenennen, die diesen Typ verwenden, und dies alles ohne wirklichen Nutzen. Wenn Sie anfangs nur einen anständigen Namen verwendet hätten, müssten Sie sich darüber keine Gedanken machen.

Was wäre, wenn Sie in Ihrem Beispiel einen sinnvolleren Typ für das Halten eines Pfads (z. B. Path) erstellt oder verwendet haben, müssen Sie Ihren m_strExePath in m_pathExePath ändern, was sehr schmerzhaft und in diesem Fall nicht sehr hilfreich ist.

5
Steve Haigh

Die einzigen zwei Bereiche, in denen ich derzeit irgendeine Form der ungarischen Schreibweise sehe, sind:

  • Klassenmitgliedsvariablen mit einem führenden Unterstrich (z. B. _someVar)
  • WinForms und WebForms-Steuerelementnamen (btn für Button, lbl für Label usw.)

Der führende Unterstrich bei den Mitgliedsvariablen scheint so, als würde er noch eine Weile bei uns bleiben, aber ich glaube, dass die Beliebtheit der ungarischen Kontrollnamen schwächer wird.

3
Richard Everett

Wenn die ungarische Schreibweise tief im Herzen Ihres und Ihres Teams und Ihres Unternehmens liegt, verwenden Sie sie auf jeden Fall. Es wird nicht mehr als Best Practice angesehen, soweit ich es in Blogs und Büchern lesen kann.

1
Otávio Décio

Wenn Sie den Zeiger über die Variable in VS halten, wird Ihnen mitgeteilt, um welchen Variablentyp es sich handelt. Es gibt also keinen Grund, diese kryptischen Variablennamen zu verwenden, zumal Personen, die aus anderen Sprachen kommen, möglicherweise den Code und pflegen müssen Es wird ein Hindernis für das einfache Lesen sein.

1
James Black

In der meisten ungarischen Schreibweise wird beschrieben, was die Variable ist (ein Zeiger oder ein Zeiger auf einen Zeiger oder der Inhalt eines Zeigers usw.) und worauf die Sache verweist, auf die sie verweist (String usw.).

Ich habe sehr wenig Verwendung für Zeiger in C # gefunden, insbesondere wenn es keine unmanaged/pinvoke-Aufrufe gibt. Es gibt auch keine Option zur Verwendung von void *, so dass kein Ungar die Beschreibung beschreiben muss.

Der einzige Rest aus dem Ungarischen, den ich (und die meisten anderen in C # land) verwende, ist, privaten Feldern mit _ vorzugehen, wie in _customers;

1
Steve Dunn

Die ungarische Notation fand ihre erste große Verwendung in der Programmiersprache BCPL . BCPL ist die Abkürzung für Before C Programming Language und ist eine uralte (1966 entworfene), typlose Sprache, in der alles ein Word ist. In dieser Situation kann die ungarische Notation bei der Typüberprüfung mit bloßem Auge helfen.

Viele Jahre sind seitdem vergangen ...

Folgendes sagt die neueste Linux-Kernel-Dokumentation (mutige Mine):

Die Kodierung des Typs einer Funktion in den Namen (sogenannte ungarische - Notation) ist hirngeschädigt - der Compiler kennt die Typen sowieso und kann Die und nur diese prüfen verwirrt den Programmierer.

Bitte beachten Sie auch, dass es zwei Arten der ungarischen Schreibweise gibt:

  • Ungarische Notation des Systems : Das Präfix codiert physisch Datentyp.

  • Apps Ungarische Notation : Das Präfix encodes logisch Datentyp.

System Ungarische Notation wird aufgrund der Redundanz der Typenüberprüfung nicht mehr empfohlen, was wiederum auf die Weiterentwicklung der Compiler-Funktionen zurückzuführen ist. Sie können jedoch weiterhin die ungarische Schreibweise von Apps verwenden, wenn der Compiler keine logischen Datentypen für Sie prüft. Als Faustregel gilt, dass die ungarische Notation genau dann gut ist, wenn sie Semantik beschreibt, die ansonsten nicht verfügbar ist.

0
Cyker

Irgendwann haben Sie wahrscheinlich eine Immobilie

public string ExecutablePath { ... }

(Nicht dass Sie versuchen sollten, Abkürzungen wie "Exe" zu vermeiden). In diesem Fall ist Ihre Frage dann meistens irrelevant, da Sie die Auto-Eigenschaften von C # 3.0 verwenden können

public string ExecutablePath { get; set; }

sie müssen jetzt keinen Namen für die Backing Store-Variable mehr angeben. Kein Name, keine Frage/Debatte über Namenskonventionen.

Selbstverständlich sind automatisch implementierte Eigenschaften nicht immer angemessen.

0
Ðаn

Es geht um Effizienz. Wie viel Zeit wurde damit verschwendet, einer Variablen den falschen Wert zuzuweisen. Mit genauen Variablendeklarationen geht es um Effizienzgewinn. Es geht um Lesbarkeit. Es geht darum, den bestehenden Mustern zu folgen. Wenn Sie Kreativität wünschen, führen Sie die Gestaltung der Benutzeroberfläche und die Systemarchitektur durch. Wenn Ihre Programmierung so gestaltet ist, dass Sie Ihren Teammitgliedern die Arbeit erleichtern, nicht Ihre. Ein Effizienzgewinn von 2% bedeutet eine zusätzliche Woche pro Jahr. Das sind 40 Stunden gewonnen. Die Steigerung der Produktivität der Menschen wird durch die Steigerung der Effizienz erreicht.

0
Shawn

In einer Sprache wie C #, in der viele der Einschränkungen für die Länge der Variablennamen nicht vorhanden sind, die einmal in Sprachen wie C und C++ vorhanden waren, und in der IDE eine ausgezeichnete Unterstützung für die Bestimmung des Variablentyps bietet, die ungarische Schreibweise ist überflüssig.

Code sollte selbsterklärend sein, so dass Namen wie m_szName durch this.name ersetzt werden können. Und m_lblName kann nameLabel usw. sein. Wichtig ist, konsistent zu sein und Code zu erstellen, der einfach zu lesen und zu verwalten ist. Dies ist das Ziel einer beliebigen Namenskonvention. Daher sollten Sie immer entscheiden, welche Konvention Sie verwenden. Ich glaube, dass die ungarische Notation nicht die lesbarste oder wartungsfähigste ist, weil sie zu knapp sein kann, ein gewisses Maß an Wissen über die Präfixe erfordert und nicht Teil der Sprache ist und daher schwer durchzusetzen und schwer zu entdecken ist wenn der Name nicht mehr mit dem zugrunde liegenden Typ übereinstimmt.

Stattdessen möchte ich Apps Hungarian (Präfixe wie m_) ersetzen, indem Sie auf this für Mitglieder, den Klassennamen für statische Variablen und kein Präfix für lokale Variablen verweisen. Statt System Ungarisch (einschließlich des Variablentyps im Variablennamen) beschreibe ich lieber, wofür die Variable steht, beispielsweise nameLabel, nameTextBox, count und databaseReference.

0
Jeff Yates

Es hängt davon ab, ob. 

Ist es signifikant genug, um die Beschreibung des Datentyps in Variable/Objektname in Ihrer Methode/Klasse hinzuzufügen?

System Ungarische Notation> Apps Ungarische Notation  

Wenn Sie in einer prozeduralen Sprache (z. B. C) entwerfen, die viele globale Variablen oder/und eine untere API enthält, die sich mit genauen Datentypen und -größen befasst (z. B. Cs<stdint.h>where 40+ verschiedene Datentypnotationen zur Beschreibung von int), System Die ungarische Notation ist hilfreicher.

Viele moderne Programmierer halten es jedoch für ausreichend, Typinformationen in Variablennamen hinzuzufügen, da viele der modernen IDEs über sehr praktische Werkzeuge verfügen (z. B. Outline von Eclipse, Symbol Navigator von Xcode, Visual AssistX von Visual Studio usw.). Die ungarische Systemnotation wurde in früheren Zeitaltern in der Programmierung (z. B. FORTRAN, C99) häufig verwendet, wenn Typinformationen nicht als Werkzeug der IDEs verfügbar waren.

System Ungarische Notation <Apps Ungarische Notation  

Wenn Sie in einer übergeordneten Klasse oder Methode arbeiten (z. B. benutzerdefinierte Treiberklasse/Methode für Ihre C # -Anwendung), reicht es möglicherweise nicht aus, den einfachen Datentyp anzugeben, um die Variable/das Objekt zu beschreiben. Daher verwenden wir in diesem Fall Apps Ungarische Notation.

Wenn der Zweck Ihrer Methode beispielsweise darin besteht, den ausführbaren Pfad abzurufen und eine Fehlermeldung anzuzeigen, wenn sie nicht gefunden wird, anstatt zu bemerken, dass es sich um einen Typ von string handelt, beachten Sie wichtige Informationen zur Beschreibung der Variablen/des Objekts für Programmierer, um sie besser zu beschreiben den Zweck der Variablen/des Objekts verstehen:

private string mPathExe;
private string msgNotFound;
0
melvynkim