Warum soll ich nicht verwenden „Ungarische Notation“?

StackOverflow https://stackoverflow.com/questions/111933

Frage

Ich weiß, was ungarische bezieht sich auf - die Informationen über eine Variable, ein Parameter oder Typ als Präfix zu seinem Namen. Jeder scheint dagegen rabiat zu sein, auch wenn in einigen Fällen scheint es eine gute Idee zu sein. Wenn ich das Gefühl, dass nützliche Informationen werden vermittelt werden, warum nicht sollte ich es genau dort, wo es verfügbar ist?

Siehe auch: Haben die Leute das nutzen ungarische Namenskonventionen in der realen Welt?

War es hilfreich?

Lösung

Die meisten Leute benutzen ungarische Notation in einer falschen Weise und werden immer zu falschen Ergebnissen.

Lesen Sie diesen ausgezeichneten Artikel von Joel Spolsky: machen Falscher Code Falscher Schauen

Kurz gesagt, ungarische Notation, wo Sie Ihre Variablennamen mit ihrem type Präfix (string) (Systeme ungarisch) ist schlecht, weil es sinnlos ist.

Ungarische Notation, wie es vom Autor beabsichtigt war, in dem Sie die Variablennamen mit seinem kind Präfix (Joels Beispiel: Sicherer String oder unsicheres String)., So genannte Apps Ungar hat seine Verwendungen und ist immer noch wertvoll

Andere Tipps

vUsing eine ungarische Notation vmakes nreading ncode schwierig.

Joel ist falsch, und hier ist der Grund.

Die "Anwendung" -Informationen er spricht sollte in der Art System codiert werden . Sie sollen nicht auf Spiegeln Variablennamen ab, um sicherzustellen, dass Sie nicht zu einem unsicheren Daten an Funktionen erfordern sichere Daten passieren können. Sie sollten es sich um eine Art Fehler machen, so dass es unmöglich , dies zu tun. Unsichere Daten sollten einen Typen haben, die als unsicher markiert, so dass es einfach nicht auf eine sichere Funktion übergeben werden. Zur Umwandlung von unsicher sicher sollte Verarbeitung mit irgendeiner Art von einer sanitize Funktion benötigen.

Viele der Dinge, die Joel spricht von als „Arten“ sind nicht Art; sie sind in der Tat Typen.

Was die meisten Sprachen fehlen jedoch ist eine Art System, das diese Art von Unterscheidungen zu erzwingen ausdrucksstark genug ist. Zum Beispiel, wenn C eine Art „starken typedef“ hat (wo die typedef Namen alle Operationen des Basistypen hatten, aber war es nicht konvertibel) dann viele diese Probleme verschwinden würden. wenn Sie könnten zum Beispiel sagen, einzuführen strong typedef std::string unsafe_string; einen neuen Typs unsafe_string, die nicht zu einem std :: string umgewandelt werden könnten (und so in der Überladungsauflösung teilnehmen könnte etc. etc.), dann würden wir nicht dumm Präfixe müssen.

Also, die zentrale Forderung, die ungarischen für Dinge, die nicht Typen sind, ist falsch. Es ist für Typ-Informationen verwendet werden. Richer Typinformationen als die traditionellen C-Typinformationen, sicher; es Informationen geben, die irgendeine Art von semantischem Detail codiert den Zweck der Objekte anzuzeigen. Aber es ist immer noch Informationen geben, und die richtige Lösung ist schon immer in das Typsystem zu kodieren. Encoding in das Typsystem ist bei weitem der beste Weg, die richtige Validierung und Durchsetzung der Vorschriften zu erhalten. Variablen-Namen einfach nicht schneiden den Senf.

Mit anderen Worten, sollte das Ziel sein, nicht „falscher Code machen, um den Entwickler falsch aussehen“. Es sollte "machen falschen Code falsch aussehen an den Compiler " sein.

Ich denke, es massiv clutters den Quellcode.

Es ist auch gewinnen Sie nicht viel in einer stark typisierte Sprache. Wenn Sie irgendeine Form von Typenkonflikt tomfoolery tun, wird der Compiler Ihnen davon erzählen.

ungarische Notation macht nur Sinn, in Sprachen ohne benutzerdefinierte Typen . In einer modernen funktionalen oder OO-Sprache, würden Sie Informationen über die „Art“ von Wert in den Datentyp oder Klasse anstatt in die Variablennamen kodieren.

Mehr Antworten verweisen Joels Artikel . Beachten Sie jedoch, dass sein Beispiel in VBScript ist, die keine benutzerdefinierten Klassen hat Unterstützung (für eine lange Zeit zumindest). In einer Sprache mit benutzerdefinierten Typen würden Sie das gleiche Problem durch eine HtmlEncodedString-Art zu schaffen, lösen und dann die Write-Methode nur das akzeptieren lassen. In einer statisch typisierten Sprache, wird der Compiler keine Codierung-Fehler abzufangen, in eine dynamisch typisierte Sie würde eine Laufzeitausnahme - aber in jedem Fall sind Sie geschützt gegen nicht-codierten Strings zu schreiben. Ungarische Bezeichnungen nur drehen den Programmierer in einen menschlichen Typ-Checker, mit der Art der Arbeit, die typischerweise besser durch Software behandelt wird.

Joel unterscheidet zwischen „-Systeme ungarisch“ und „apps ungarisch“, wobei „Systeme ungarisch“ kodiert die eingebauten Typen wie int, float und so weiter, und „apps ungarisch“ codiert „Arten“, die auf höherer Ebene ist Meta-Informationen über Variable beyound Maschinentyp in einem OO oder moderner funktionaler Sprache, die Sie benutzerdefinierte Typen erstellen können, so gibt es keinen Unterschied zwischen Typ und „Art“ in diesem Sinne - sowohl durch die Art System dargestellt werden kann - und „Apps“ ungarisch ist ebenso überflüssig wie „Systeme“ ungarisch.

So Ihre Frage zu beantworten: System ungarisch würde nur in einer unsicheren, schwach typisierte Sprache nützlich sein, wenn z.B. einen Gleitkommawert in einem int Variablen zugewiesen wird, das System zum Absturz bringen. Ungarische Notation wurde speziell in den sechziger Jahren für die Verwendung erfunden in BCPL , eine ziemlich Low-Level-Sprache, die didn ‚t jede Art bei allen Produkten zu überprüfen. Ich denke nicht, jede Sprache im allgemeinen Gebrauch heute dieses Problem hat, aber die Schreibweise lebte als eine Art Cargo-Kult-Programmierung .

Apps ungarisch werden Sinn machen, wenn Sie mit einer Sprache ohne benutzerdefinierte Typen, wie Legacy-VBScript oder frühe Versionen von VB arbeiten. Vielleicht auch frühe Versionen von Perl und PHP. Wieder ist es in einem modernen languge verwendet, ist reiner Cargo-Kult.

In einer anderen Sprache ist ungarisch nur hässlich, überflüssig und zerbrechlich. Er wiederholt Informationen bereits aus dem Typ-System bekannt und Sie sollten sich nicht wiederholen . Verwenden Sie einen beschreibenden Namen für die Variable, die die Absicht dieser speziellen Instanz des Typs beschreibt. Verwenden Sie das Typsystem zu kodieren, Invarianten und Meta Infos zu „Art“ oder „Klassen“ von Variablen - dh. Typen.

Der allgemeine Punkt von Joels Artikel - falschen Code aussehen falsch zu haben - ist ein sehr gutes Prinzip. Doch ein noch besserer Schutz gegen Fehler ist - wenn überhaupt möglich -. Falschen Code automatisch vom Compiler erkannt werden

I ungarische Notation immer für alle meine Projekte verwenden. Ich finde es sehr hilfreich, wenn ich mit 100s von verschiedenen Bezeichnernamen zu tun habe.

Zum Beispiel, wenn ich rufe eine Funktion eine Zeichenfolge erforderlich Typ I kann ‚s‘ und die Treffersteuer-Raum und meine IDE zeigt mir genau die Variablennamen mit dem Präfix ‚s‘.

Ein weiterer Vorteil, wenn ich u für unsigned Präfix und i für signierte Ints, habe ich sofort sehen, wo ich in potenziell gefährlicher Weise und ohne Vorzeichen am Mischen.

Ich kann nicht die Anzahl, wie oft denken Sie daran, wenn sie in einer riesigen 75000 Linie Code-Basis, Fehler verursacht wurden (von mir und anderen auch) aufgrund lokale Variablen des gleichen wie bestehender Membervariablen dieser Klasse zu benennen. Seitdem habe ich immer Präfix Mitglieder mit ‚m _‘

Es ist eine Frage des Geschmacks und Erfahrung. nicht klopfen, bis du es versucht haben.

Sie vergessen die Zahl ein Grund, diese Information aufzunehmen. Es hat nichts mit dir zu tun, den Programmierer. Es hat alles, was mit der Person kommt auf dem Weg 2 oder 3 Jahre zu tun, nachdem Sie das Unternehmen verlassen, das das Zeug lesen hat.

Ja, es wird ein IDE schnell Typen für Sie identifizieren. Allerdings, wenn Sie durch einige lange Chargen von ‚Geschäftsregeln‘ Code lesen, es ist schön, nicht auf jede Variable pausieren, um herauszufinden, welche Art es ist. Wenn ich sehe Dinge wie strUserID, intProduct oder guiProductID, macht es für viel leichter 'ramp up' Zeit.

Ich bin damit einverstanden, dass MS mit einigen ihrer Namenskonventionen viel zu weit gegangen. - Ich kategorisieren, dass in der „zu viel des Guten“ Haufen

Namenskonventionen sind gute Dinge, vorausgesetzt, Sie bei ihnen bleiben. Ich habe genug durch alten Code gegangen, das hatte mich zurück zu ständig für so viele an den Definitionen sehen ähnlich benannten Variablen, die ich „Kamel Gehäuse“ drücken (wie es bei einem früheren Job genannt wurde). Im Moment bin ich auf einen Job, der viele tausend Zeilen völlig unkommentiert klassischen ASP-Code mit VBScript hat und es ist ein Alptraum versucht, die Dinge zu verstehen.

Wenden auf kryptische Zeichen am Anfang jeden Variablennamen ist nicht erforderlich, und zeigt, dass der Variablenname selbst nicht aussagekräftig genug ist. Die meisten Sprachen benötigen Sie den Variablentyp bei der Deklaration ohnehin, so dass die Informationen bereits verfügbar ist.

Es gibt auch die Situation, bei der Wartung ein Variablentyp geändert werden muss. Beispiel: Wenn eine Variable als „uint_16 u16foo“, erklärte eine 64-Bit ohne Vorzeichen zu werden braucht, eine von zwei Dingen passieren:

  1. Du wirst gehen und ändern jeden Variablennamen (sicherstellen, dass keine unabhängige Variablen mit dem gleichen Namen mit dem Schlauch) oder
  2. Sie einfach die Art ändern und nicht den Namen ändern, die nur Verwirrung stiften wird.

Joel Spolsky schrieb eine gute Blog-Post über diese. http://www.joelonsoftware.com/articles/Wrong.html Grundsätzlich kommt es auf Ihren Code nicht machen schwerer zu lesen, wenn eine anständige IDE wird Ihnen sagen, geben Sie wollen, dass die Variable ist, wenn Sie nicht mehr erinnern kann. Auch, wenn Sie Ihren Code in Kompartimente genug machen, müssen Sie sich nicht mehr daran erinnern, was eine Variable als drei Seiten nach oben erklärt wurde.

Ist das nicht Anwendungsbereich wichtiger als in diesen Tagen zu geben, z. 

* l for local
* a for argument
* m for member
* g for global
* etc

Mit modernen Techniken der alten Code Refactoring, suchen und ein Symbol ersetzen, weil Sie seine Art geändert mühsam ist, wird der Compiler Typänderungen fangen, aber oft nicht falsche Verwendung von Umfang fangen, vernünftige Namenskonventionen hier helfen.

Es gibt keinen Grund, warum sollten Sie nicht richtig Gebrauch der ungarischen Notation machen. Es ist unbeliebt ist auf einen lang andauernde Rück Peitsche gegen den falschen Gebrauch der ungarischen Notation, vor allem in den Windows-APIs.

In den schlechten alten Tagen, bevor irgendetwas ein IDE existierte für DOS ähnelt (Odds sind Sie nicht genügend freien Speicher haben den Compiler unter Windows ausgeführt werden, so dass Ihre Entwicklung in DOS getan wurde), werden Sie nicht bekommen jede Hilfe von der Maus über einen Variablennamen schweben. (Sie Unter der Annahme hatte eine Maus.) Was hast du getan hast mit Funktionen waren Ereignisrückruf zu tun haben, in dem sich alles um Sie entweder als ein 16-Bit-int übergeben wurde (WORD) oder 32-Bit-int (LONG WORD). Sie haben dann diese Parameter an die entsprechenden Typen für den gegebenen Ereignistyp zu werfen. In der Tat war ein großer Teil der API praktisch typ weniger.

Das Ergebnis, eine API mit Parameternamen wie diese: 

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

Beachten Sie, dass die Namen wParam und lParam, obwohl ziemlich schrecklich, sind nicht wirklich schlechter als sie param1 und param2 zu nennen.

Erschwerend kommt hinzu, Fenster 3.0 / 3.1 hatten zwei Arten von Zeigern, nah und fern. So zum Beispiel der Rückgabewert aus dem Speicher-Management-Funktion LocalLock war ein PVOID, aber der Rückgabewert von GlobalLock war ein LPVOID (mit ‚L‘ für lange). Diese schreckliche Notation wurde dann erweitert, so dass ein l Ong p ointer String Präfix wurde lp , es aus einer Zeichenfolge zu unterscheiden, die malloc einfach gewesen ‚d.

Es ist keine Überraschung, dass es ein Spiel gegen diese Art der Sache war.

Ungarische Notation kann ohne Kompilierung Typüberprüfung in Sprachen nützlich sein, da es Entwickler schnell erlauben würde, sich daran erinnern, wie die bestimmte Variable verwendet wird. Es tut nichts zur Leistung oder Verhalten. Es sollte die Lesbarkeit des Codes verbessern und ist vor allem eine Frage einen Geschmack und Programmierstil. Aus diesem Grunde ist es von vielen Entwicklern kritisiert - nicht jeder die gleiche Verdrahtung im Gehirn hat

.

Für die Kompilierung-Typ-Überprüfung Sprachen ist es meist nutzlos - ein paar Zeilen Scrollen nach oben sollte die Deklaration und so geben Sie offenbaren. Wenn Sie globale Variablen oder Ihre Codeblock Spannweiten für viel mehr als einen Bildschirm, haben Sie Grab Design und Wiederverwertbarkeit Fragen. So ist eine der Kritik ist, dass die ungarische Notation Entwickler schlechtes Design haben kann und leicht weg mit ihm. Dies ist wahrscheinlich einer der Gründe für hatered.

Auf der anderen Seite kann es Fälle geben, wo selbst kompilieren Zeittypprüfung Sprachen aus dem Ungarischen Notation profitieren würden - void Zeiger oder GREIFT 's in win32 API. Diese verschleiert den tatsächlichen Datentyp, und es könnte ein Vorteil sein, da ungarische Notation zu verwenden. Doch wenn man die Art der Daten bei der Erstellung wissen kann, warum nicht den entsprechenden Datentyp verwenden.

In der Regel gibt es keine harten Gründe nicht ungarische Notation zu verwenden. Es ist eine Frage der Gleichen, Richtlinien und Programmierstil.

Als Python-Programmierer, fällt ungarische Notation auseinander schnell hübsch. In Python, ist mir egal, ob etwas ist ein String - ist mir egal, ob es kann wirken wie eine Zeichenkette (dh, wenn es eine ___str___() Methode hat, die einen String zurückgibt) .

Zum Beispiel, sagen wir, wir haben foo als eine ganze Zahl, 12 

foo = 12

ungarische Notation sagt uns, dass wir diese IFoo oder etwas nennen soll, bezeichnen, es ist eine ganze Zahl, so dass später, wissen wir, was es ist. Außer in Python, funktioniert das nicht, oder besser gesagt, macht es keinen Sinn machen. In Python, ich entscheiden, welche Art ich will, wenn ich es verwenden. Will ich einen String? gut, wenn ich so etwas tun: 

print "The current value of foo is %s" % foo

Beachten Sie die %s - String. Foo ist kein String, aber der % werden von einem Operator foo.___str___() aufrufen und das Ergebnis verwenden (vorausgesetzt, es existiert). foo ist nach wie vor eine ganze Zahl, aber wir behandeln es als eine Zeichenfolge, wenn wir eine Zeichenfolge wollen. Wenn wir einen Schwimmer wollen, dann behandeln wir es als Schwimmer. In dynamisch typisierten Sprachen wie Python, ungarische Notation ist sinnlos, weil es keine Rolle spielt, welche Art etwas ist, bis Sie es verwenden, und wenn Sie eine bestimmte Art benötigen, dann nur sicherstellen, dass es auf diese Art werfen (zB float(foo)), wenn Sie verwenden es.

Hinweis

, dass dynamische Sprachen wie PHP nicht diesen Vorteil haben - PHP versucht zu tun ‚das Richtige‘ im Hintergrund basierte auf einem obskuren Satz von Regeln, die fast niemand gemerkt hat, was oft zu katastrophalen Verwirrungen unerwartet. In diesem Fall Mechanismus eine Art zu nennen, wie $files_count oder $file_name, kann nützlich sein.

Aus meiner Sicht ungarische Notation ist wie Blutegel. Vielleicht in der Vergangenheit waren sie nützlich, oder zumindest schienen sie nützlich, aber es ist heute nur eine Menge zusätzlicher Eingabe für nicht viel Nutzen.

Die IDE sollten, die nützlichen Informationen vermitteln. Ungarisch könnte eine Art gemacht haben (nicht viel, aber eine Art) von Sinn, wenn IDE viel weniger weit fortgeschritten waren.

Apps Ungarisch ist Griechisch für mich - in einem guten Weg

Als Ingenieur, kein Programmierer, nahm ich sofort zu Joels Artikel über die Vorzüge von Apps Ungarisch: " Making Falscher Code Falscher Look ". Ich mag Apps Ungarisch, weil es imitiert, wie Maschinenbau, Naturwissenschaften und Mathematik darstellen Gleichungen und Formeln mit Sub- und Super-Skript Symbolen (wie griechische Buchstaben, mathematische Operatoren, etc.). Nehmen Sie ein besonderes Beispiel für Newtons Gesetz der universellen Gravitation : zuerst in der mathematischen Standardnotation und dann in Apps ungarischen Pseudo-Code:

Newtons universelles Gesetz der Schwerkraft für die Erde und Mars 

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

In der mathematischen Notation, die prominentesten Symbole in den Variablen diejenigen, die die Art von Informationen gespeichert sind: Kraft, Masse, Positionsvektor usw. Die Indizes des zweite Geige spielen zu klären: Position Was? Dies ist genau das, was Apps ungarische tut; es sagt dir die Art von gespeichert, was in den Variable und dann ins Detail immer - über den nächsten Code kann eine mathematische Schreibweise erhalten.

Klar starke Typisierung kann die sichere gegen unsicheres String Beispiel von Joel Essay beheben, aber Sie würden getrennte Typen für die Positions- und Geschwindigkeitsvektoren nicht definieren; beide sind Doppel Arrays der Größe drei und alles, was Sie wahrscheinlich eine tun, um die andere Anwendung finden könnte. Darüber hinaus ist es durchaus sinnvoll, Position und Geschwindigkeit zu verketten (um einen Zustandsvektor zu machen) oder deren Skalarprodukt nehmen, aber wahrscheinlich nicht um sie hinzuzufügen. Wie würde die Eingabe der ersten beiden ermöglichen und die zweite verbieten, und wie würde ein solches System zu jeder möglichen Betrieb erweitern Sie schützen möchten? Es sei denn, Sie waren bereit, alle Mathematik und Physik in Ihrem Typisierungssystem zu kodieren.

Am Anfang aller, dass viele Engineering in schwach typisierte Hochsprachen wie Matlab, oder alten wie Fortran 77 oder Ada.

Wenn Sie also eine Phantasie Sprache und IDE und Apps Ungarisch haben hilft Ihnen nicht, dann vergessen Sie es - viele Leute haben offenbar. Aber für mich ein schlimmer als ein Anfänger-Programmierer, der schwach arbeiten in oder dynamisch typisierten Sprachen, kann ich besser Code schneller mit Apps ungarischen schreiben als ohne.

Es ist unglaublich überflüssig und nutzlos ist modernsten IDEs, wo sie einen guten Job machen offensichtlich die Art der Herstellung.

Plus - für mich - es ist einfach ärgerlich zu sehen intI, strUserName usw.:)

  

Wenn ich das Gefühl, dass nützliche Informationen vermittelt werden, warum nicht sollte ich es genau dort, wo es verfügbar ist?

Dann, wer sich interessiert, was jemand anderes denkt? Wenn Sie es nützlich finden, dann die Notation.

Im meiner Erfahrung, es ist schlecht, weil:

1 - dann brechen Sie alle Code, wenn man den Typ einer Variablen ändern müssen (das heißt wenn Sie ein 32-Bit-Ganzzahl in eine 64 Bit Ganzzahl verlängern);

2 - das ist nutzlose Informationen wie die Art ist entweder bereits in der Deklaration oder Sie verwenden eine dynamische Sprache, wo der tatsächliche Typ nicht so wichtig, in erster Linie sein sollte

.

Darüber hinaus mit einer Sprache, die generische Programmierung zu akzeptieren (dh Funktionen, bei denen die Art einiger Variablen nicht bestimmen, wann Sie die Funktion schreiben) oder mit dynamischer Typisierung System (dh, wenn die Art bestimmt, ist nicht einmal bei der Kompilierung), wie würde Sie nennen Ihre Variablen? Und die meisten modernen Sprachen unterstützen das eine oder andere, wenn auch in eingeschränkter Form.

Joel Spolsky machen Falscher Code Falscher Schauen er erklärt, dass, was jeder denkt an als ungarische Notation (die er Systeme ungarische nennt) ist nicht das, was es war wirklich gedacht war (wie er es nennt Apps ungarisch). Blättern Sie nach unten auf die Schaltfläche Ich bin Ungarn Überschrift diese Diskussion zu sehen.

Im Grunde Systeme ungarischen ist wertlos. Es sagt Ihnen, nur die gleiche Sache Compiler und / oder IDE wird Ihnen sagen.

Apps Ungar sagt Ihnen, was die Variable bedeuten soll, und kann tatsächlich nützlich sein.

Ich habe immer gedacht, dass ein Präfix oder zwei an der richtigen Stelle würde nicht schaden. Ich denke, wenn ich etwas Nützliches, wie vermitteln kann „Hey, das ist eine Schnittstelle, zählen nicht auf ein bestimmtes Verhalten“ genau dort, wie in IEnumerable, ich oughtta es tun. Ein Kommentar Dinge verunstaltet viel mehr als nur ein oder zwei Zeichensymbol.

Es ist eine nützliche Konvention für Steuerelemente in einem Formular (btnOK, txtLastName etc.), wenn die Liste der Kontrollen zeigt sich in einer alphabetisch geordneten Pull-Down-Liste in der IDE zu nennen.

neige ich dazu, ungarische Notation mit ASP.NET-Steuerelemente verwenden nur , sonst ich es zu schwer finden, um herauszufinden, was Kontrollen sind das, was auf dem Formular.

Nehmen Sie den Code-Snippet: 

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

Wenn jemand einen besseren Weg zu haben, dass die Menge von Steuer Namen ohne ungarischen zeigen kann ich versucht sein würde, um es zu bewegen.

Joels Artikel ist groß, aber es scheint ein wichtiger Punkt auszulassen:

Ungarisch macht eine besondere ‚Idee‘ (Art + Bezeichnernamen) einzigartig, oder nahezu einzigartig, über die Code-Basis -. auch eine sehr große Code-Basis

Das ist riesig für die Codepflege. Es bedeutet, dass Sie eine gute ol‘einzeilige Textsuche verwenden können, (Grep, findstr, 'in allen Dateien finden') JEDE Erwähnung dieser 'Idee' zu finden.

Warum ist das wichtig, wenn wir IDE haben, die wissen, wie Code zu lesen? Weil sie es noch nicht sehr gut sind. Das ist schwer in einer kleinen Code-Basis zu sehen, aber offensichtlich in einem großen ein - wenn die ‚Idee‘ könnte in den Kommentaren erwähnt werden, XML-Dateien, Perl-Skripte, und auch an Orten außerhalb der Quellcodeverwaltung (Dokumente, Wikis, Bug-Datenbanken).

Sie haben ein wenig vorsichtig, auch hier zu sein - z.B. Token-Einfügen in C / C ++ Makros verstecken erwähnt der Kennung kann. Solche Fälle können bei der Verwendung behandelt werden Konventionen Codierung, und trotzdem neigen sie nur eine Minderheit der Identifikatoren in der beeinflussen Code-Basis.

P. S. Auf den Punkt über das Typsystem gegen ungarischen mit - es ist am besten, beide zu verwenden. Sie müssen nur falschen Code falsch suchen, wenn die Compiler es nicht für Sie fangen. Es gibt viele Fälle, in denen es unmöglich ist, zu den Compiler es zu machen zu fangen. Aber wo es machbar ist - ja, bitte, dass statt!

Wenn Machbarkeit unter Berücksichtigung, aber tun, um die negativen Auswirkungen der Aufspaltung Typen berücksichtigen. z.B. in C #, ‚int‘ mit einer nicht-eingebauten Typ hat enorme Konsequenzen wickelt. So macht es Sinn, in einigen Situationen, aber nicht in allen.

Debunking die Vorteile der ungarischen Notation

  • Es bietet eine Möglichkeit zur Unterscheidung von Variablen.

Wenn der Typ alles ist, was den einen Wert von einem anderen unterscheidet, dann kann es nur auf einem anderen für die Umwandlung von einer Art sein. Wenn Sie den gleichen Wert haben, der zwischen den Typen umgewandelt wird, stehen die Chancen, sollten Sie dies in einer Funktion Umwandlung gewidmet tun. (ich habe hungarianed VB6 Reste Saiten verwenden Sie einfach auf all ihre Methodenparameter zu sehen, weil sie nicht heraus konnten, wie ein JSON-Objekt deserialisieren, oder richtig verstehen, wie oder Nullable-Typen verwenden zu erklären. ) Wenn Sie haben nur zwei von der ungarischen Präfix unterscheiden Variablen, und sie sind nicht eine Umwandlung von einem zum anderen, dann müssen Sie mit ihnen auf Ihre Absicht auszuarbeiten.

  • Es macht den Code besser lesbar.

Ich habe festgestellt, dass die ungarische Schreibweise Menschen faul mit ihren Variablennamen macht. Sie haben etwas, das es durch zu unterscheiden, und sie fühlen keine Notwendigkeit, um ihren Zweck zu erarbeiten. Dies ist, was Sie in der Regel in der ungarischen notierter Code vs. modern finden. SSQL vs. groupSelectSql ( oder in der Regel keine sSQL überhaupt, weil sie die ORM werden sollen verwenden, wurde von früheren Entwicklern setzen in ), sValue vs. formCollectionValue ( oder in der Regel entweder keine sValue, weil sie in MVC zu passieren, und sollte sein Modell Bindungseigenschaften ), sType vs. publish, etc.

verwenden

Es kann nicht Lesbarkeit sein. Ich sehe mehr sTemp1, sTemp2 ... sTempN von einem bestimmten hungarianed VB6 Überbleibsel als alle anderen zusammen.

  • Es vermeidet Fehler.

Dies auf Grund Nummer 2 sein würden, was falsch ist.

Mit den Worten des Meisters:

http://www.joelonsoftware.com/articles/Wrong.html

Eine interessante Lektüre, wie üblich.

Auszüge:

"Jemand, irgendwo, Simonyi Papier lesen, wo er das Wort‚Typ‘, und dachte, dass er Art gemeint, wie Klasse, wie in einem Typ-System, wie der Typ überprüft, dass der Compiler tut. Er tat es nicht. Ihn sehr sorgfältig erklärte genau, was er mit dem Wort gemeint „Typ“, aber es hat nicht geholfen. der Schaden wurde. "

"Aber es gibt immer noch eine enorme Menge an Wert Apps Ungarisch, dass es Kollokations im Code erhöht, was den Code leichter lesen macht, schreiben, debuggen und warten und, was am wichtigsten ist, ist es falsch Code aussieht falsch ".

Stellen Sie sicher, dass Sie einige Zeit haben, bevor Joel On Software zu lesen. :)

Mehrere Gründe:

  • Jede IDE moderne geben Sie den Variablentyp, indem Sie einfach mit der Maus über die Variable schweben.
  • Namen meisten Art sind Art und Weise lang (man denke HttpClientRequestProvider ), vernünftigerweise als Präfix verwendet werden.
  • Die Typ-Information nicht tragen die rechts Informationen, es wird nur die Variablendeklaration zu paraphrasieren, statt umreißt die Zweck der Variablen (man denke myInteger vs. pagesize ).

Ich glaube nicht, jeder rabidly dagegen ist. In Sprachen ohne statische Typen, es ist ziemlich nützlich. Ich ziehe es auf jeden Fall, wenn es verwendet werden Informationen zu geben, die nicht bereits in der Art ist. Wie in C, char * szName , sagen, dass der Variable auf einen Null-terminierten String beziehen - das ist nicht implizit in char * -. Natürlich wäre ein typedef auch helfen

Joel hatte einen großen Artikel über die Verwendung ungarisch zu sagen, ob eine Variable wurde HTML codiert oder nicht:

http://www.joelonsoftware.com/articles/Wrong.html

Wie auch immer, ich neige dazu, ungarische Abneigung, wenn es verwendet werden Informationen zu vermitteln weiß ich schon.

Natürlich, wenn 99% der Programmierer auf etwas einigen, ist etwas nicht in Ordnung. Der Grund, warum sie hier zustimmen, weil die meisten von ihnen nie richtig ungarische Schreibweise verwendet haben.

Für eine detaillierte Argumentation, verweise ich Sie auf einen Blog-Post ich zu diesem Thema gemacht haben.

http://codingthriller.blogspot.com/2007/11 /rediscovering-hungarian-notation.html

Ich begann ziemlich Codierung des über die Zeit ungarische Notation erfunden wurde und das erste Mal, dass ich gezwungen war, es an einem Projekt zu verwenden, ich hasste es.

Nach einer Weile wurde mir klar, dass, wenn es richtig gemacht wurde es hat tatsächlich zu helfen, und in diesen Tagen, ich liebe es.

Aber wie alle Dinge gut, hat es gelernt und verstanden werden und es richtig braucht Zeit zu tun.

Die ungarische Schreibweise missbraucht wurde, vor allem von Microsoft, die länger als die Variablennamen Präfixe führt, und zeigt es ist ziemlich steif, vor allem wenn man die Typen ändern (der berüchtigte lparam / wparam, von einem anderen Typ / Größe in Win16, identisch in Win32).

So werden sowohl aufgrund dieses Missbrauch und deren Verwendung durch M $, es wurde niedergeschlagen als nutzlos.

Bei meiner Arbeit, Code, den wir in Java, aber der Gründer Cames von MFC Welt, so verwenden ähnlichen Code-Stil (ausgerichtet Klammern, Ich mag diese !, Kapitelle Methodennamen, ich bin daran gewöhnt, Präfix wie m_ Klasse Mitglieder (Felder), s_ statische Mitglieder, usw.).

Und sie sprachen alle Variablen ein Präfix haben sollte, seine Art (Bsp. Ein BufferedReader heißt brData). Die als eine schlechte Idee gezeigt, wie die Typen aber der Name folgt jedoch nicht ändern können, oder Programmierer sind in der Verwendung dieser Präfixe nicht konsistent (ich selbst sehen aBuffer, theProxy usw.!).

Persönlich habe ich mich für ein paar Präfixe, die ich nützlich finden, die wichtigsten sind b boolean Variablen Präfix, da sie die einzigen sind, wo ich Syntax wie if (bVar) zulassen (keine Verwendung von Autocast einiger Werte wahr oder falsch ). Wenn ich in C codierte, habe ich einen Präfix für Variablen mit malloc, als Erinnerung, sollte es später befreit werden. Etc.

Also, im Grunde, ich weiß nicht, diese Darstellung als Ganzes ablehnen, sondern nahm, was für meine Bedürfnisse passend scheint.
Und natürlich, wenn sie an ein Projekt (Arbeit, Open Source) beitragen, verwende ich nur die Konventionen in place!

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top