it-swarm-eu.dev

Was ist der Vorteil, wenn die ungarische Notation nicht verwendet wird?

Eines der Dinge, mit denen ich zu kämpfen habe, ist, keine ungarische Notation zu verwenden. Ich möchte nicht zur Variablendefinition gehen müssen, um zu sehen, um welchen Typ es sich handelt. Wenn ein Projekt umfangreich wird, ist es schön, eine Variable mit dem Präfix 'bool' betrachten zu können und zu wissen, dass es nach true/false anstelle von /1 sucht Wert.

Ich arbeite auch viel in SQL Server. Ich stelle meinen gespeicherten Prozeduren 'sp' und meinen Tabellen 'tbl' voran, ganz zu schweigen von allen meinen Variablen in der Datenbank.

Ich sehe überall, dass niemand wirklich die ungarische Notation verwenden möchte, bis zu dem Punkt, an dem er sie vermeidet. Meine Frage ist, was ist der Vorteil, wenn nicht die ungarische Notation verwendet, und warum vermeidet die Mehrheit der Entwickler dies wie die Pest?

102
user29981

Weil seine ursprüngliche Absicht (siehe http://www.joelonsoftware.com/articles/Wrong.html und http://fplanque.net/Blog/devblog/2005/05/11)/hungarian_notation_on_steroids ) wurde missverstanden und (ab) verwendet, um Menschen dabei zu helfen, sich daran zu erinnern, welcher Typ eine Variable ist, wenn die von ihnen verwendete Sprache nicht statisch typisiert ist. In jeder statisch typisierten Sprache benötigen Sie kein zusätzliches Präfix, um zu erfahren, um welchen Typ es sich bei einer Variablen handelt. In vielen untypisierten Skriptsprachen kann es helfen, aber es wurde oft missbraucht, bis es völlig unhandlich wurde. Anstatt zur ursprünglichen Absicht der ungarischen Notation zurückzukehren, haben die Leute es leider nur zu einem dieser "bösen" Dinge gemacht, die Sie vermeiden sollten.

Kurz gesagt, die ungarische Notation sollte Variablen eine gewisse Semantik voranstellen. Wenn Sie beispielsweise Bildschirmkoordinaten haben (links, oben, rechts, unten), würden Sie Variablen mit absoluten Bildschirmpositionen "abs" und Variablen mit Positionen relativ zu einem Fenster mit "rel voranstellen. ". Auf diese Weise ist es für jeden Leser offensichtlich, wenn Sie eine relative Koordinate an eine Methode übergeben, die absolute Positionen erfordert.

Update (als Antwort auf einen Kommentar von delnan)

IMHO sollte die missbrauchte Version wie die Pest vermieden werden, weil:

  • es erschwert die Benennung. Wenn (ab) die ungarische Notation verwendet wird, wird immer diskutiert, wie spezifisch die Präfixe sein müssen. Zum Beispiel: listboxXYZ oder MyParticularFlavourListBoxXYZ.
  • dadurch werden Variablennamen länger, ohne dass das Verständnis dafür, wofür die Variable bestimmt ist, verbessert wird.
  • es besiegt das Objekt der Übung, wenn lange Präfixe auf Abkürzungen gekürzt werden und Sie ein Wörterbuch benötigen, um zu wissen, was jede Abkürzung bedeutet. Ist ein ui eine vorzeichenlose Ganzzahl? eine nicht referenzierte gezählte Schnittstelle? etwas mit Benutzeroberflächen zu tun? Und diese Dinge können lang werden . Ich habe Präfixe von mehr als 15 scheinbar zufälligen Zeichen gesehen, die den genauen Typ der Var vermitteln sollen, aber wirklich nur mystifizieren.
  • es ist schnell veraltet. Wenn Sie den Typ einer Variablen ändern, vergessen die Benutzer ausnahmslos (lol), das Präfix zu aktualisieren, um die Änderung widerzuspiegeln, oder aktualisieren Sie es absichtlich nicht, da dies überall dort Codeänderungen auslösen würde, wo die Variable verwendet wird ...
  • es erschwert das Sprechen über Code, weil als "@g." sagte: Variablennamen mit ungarischer Notation sind in der Regel schwer auszusprechende Alphabetsuppe. Dies beeinträchtigt die Lesbarkeit und die Diskussion von Code, da Sie keinen der Namen "sagen" können.
  • ... noch viel mehr, an das ich mich momentan nicht erinnern kann. Vielleicht, weil ich das Vergnügen hatte, mich lange nicht mehr mit der missbrauchten ungarischen Notation auseinandersetzen zu müssen ...
148
Marjan Venema

Die ungarische Notation ist ein Namensmuster in modernen Programmierumgebungen und eine Form von Tautologie .

Es wiederholt nutzlos Informationen ohne Nutzen und zusätzlichen Wartungsaufwand. Was passiert, wenn Sie Ihr int in einen anderen Typ wie long ändern? Jetzt müssen Sie Ihre gesamte Codebasis suchen und ersetzen, um alle Variablen umzubenennen, oder sie sind jetzt semantisch falsch, was schlimmer ist als Wenn Sie den Typ im Namen nicht dupliziert haben.

Es verstößt gegen das Prinzip DRY. Wenn Sie Ihren Datenbanktabellen eine Abkürzung voranstellen müssen, um Sie daran zu erinnern, dass es sich um eine Tabelle handelt, benennen Sie Ihre Tabellen definitiv nicht semantisch beschreibend genug. Gleiches gilt für alles andere, mit dem Sie dies tun. Es ist nur zusätzliches Tippen und Arbeiten ohne Gewinn oder Nutzen in einer modernen Entwicklungsumgebung.

74
user7519

Wikipedia hat eine Liste von Vor- und Nachteilen der ungarischen Notation und kann daher wahrscheinlich die umfassendste Antwort auf diese Frage liefern. Die bemerkenswerte Meinungen sind auch eine ziemlich interessante Lektüre.

Der Vorteil, dass nicht die ungarische Notation verwendet, ist im Grunde nur die Vermeidung seiner Nachteile:

  • Die ungarische Notation ist redundant, wenn die Typprüfung vom Compiler durchgeführt wird. Compiler für Sprachen, die eine Typprüfung ermöglichen, stellen sicher, dass die Verwendung einer Variablen automatisch mit ihrem Typ übereinstimmt. Augenkontrollen sind überflüssig und unterliegen menschlichen Fehlern.

  • Alle modernen integrierten Entwicklungsumgebungen zeigen bei Bedarf Variablentypen an und kennzeichnen automatisch Vorgänge, die inkompatible Typen verwenden, wodurch die Notation weitgehend veraltet ist.

  • Die ungarische Notation wird verwirrend, wenn sie zur Darstellung mehrerer Eigenschaften verwendet wird, wie in a_crszkvc30LastNameCol: Ein konstantes Referenzargument, das den Inhalt einer Datenbankspalte LastName vom Typ varchar(30) enthält ist Teil des Primärschlüssels der Tabelle.

  • Dies kann zu Inkonsistenzen führen, wenn Code geändert oder portiert wird. Wenn der Variablentyp geändert wird, stimmt entweder die Dekoration des Variablennamens nicht mit dem neuen Typ überein, oder der Variablenname muss geändert werden. Ein besonders bekanntes Beispiel ist der Standardtyp WPARAM und der zugehörige formale Parameter wParam in vielen Windows-Systemfunktionsdeklarationen. Das 'w' steht für 'Word', wobei 'Word' die native Word-Größe der Hardwarearchitektur der Plattform ist. Es war ursprünglich ein 16-Bit-Typ in 16-Bit-Word-Architekturen, wurde jedoch in 32-Bit-Word-Architekturen in einen 32-Bit-Typ oder in 64-Bit-Word-Architekturen in späteren Versionen des Betriebssystems unter Beibehaltung des 64-Bit-Typs geändert ursprünglicher Name (sein wahrer zugrunde liegender Typ ist UINT_PTR, dh eine vorzeichenlose Ganzzahl, die groß genug ist, um einen Zeiger aufzunehmen). Die semantische Impedanz und damit die Verwirrung und Inkonsistenz des Programmierers von Plattform zu Plattform geht davon aus, dass 'w' in diesen verschiedenen Umgebungen für 16-Bit steht.

  • Wenn Sie die Verwendung einer Variablen kennen, müssen Sie meistens ihren Typ kennen. Wenn die Verwendung einer Variablen nicht bekannt ist, kann sie nicht aus ihrem Typ abgeleitet werden.

  • Die ungarische Notation reduziert die Vorteile der Verwendung funktionsreicher Code-Editoren, die die Vervollständigung von Variablennamen unterstützen, erheblich, da der Programmierer zuerst den gesamten Typspezifizierer eingeben muss.

  • Es macht Code weniger lesbar, indem es den Zweck der Variablen mit unnötigen Typ- und Gültigkeitsbereichspräfixen verschleiert.

  • Die zusätzlichen Typinformationen können aussagekräftigere Namen nur unzureichend ersetzen. Z.B. sDatabase sagt dem Leser nicht, was es ist. databaseName könnte ein aussagekräftigerer Name sein.

  • Wenn die Namen ausreichend beschreibend sind, können die zusätzlichen Typinformationen redundant sein. Z.B. firstName ist höchstwahrscheinlich eine Zeichenfolge. Wenn Sie es also sFirstName nennen, wird der Code nur unübersichtlich.

Ich selbst benutze diese Notation nicht, weil ich das unnötige technische Rauschen nicht mag. Ich weiß fast immer, mit welchem ​​Typ ich es zu tun habe, und ich möchte eine saubere Sprache in meinem Domain-Modell, aber ich schreibe hauptsächlich in statisch und stark typisierten Sprachen.

51
Falcon

Als MS SQL Server-spezifisches Problem:

Alle gespeicherten Prozeduren mit dem Präfix 'sp_' werden zuerst in der Master-Datenbank gesucht und nicht in der Datenbank, in der sie erstellt wurden. Dies führt zu einer Verzögerung bei der Ausführung der gespeicherten Prozedur.

19
tsundoku

IMO ist der größte Vorteil, wenn Sie kein Ungarisch verwenden, die Tatsache, dass Sie gezwungen sind, aussagekräftige Namen zu verwenden. Wenn Sie Variablen richtig benennen, sollten Sie sofort wissen, um welchen Typ es sich handelt, oder in einem gut gestalteten System relativ schnell darauf schließen können. Wenn Sie sich auf str oder bln oder noch schlimmer auf alle obj Präfixe verlassen müssen, um zu wissen, welcher Typ eine Variable ist, würde ich argumentieren, dass dies auf ein Namensproblem hinweist - entweder eine schlechte Variable Namen im Allgemeinen oder viel zu allgemein, um Bedeutung zu vermitteln.

Aus persönlicher Erfahrung ist das Hauptszenario, das ich als ungarisch gesehen habe, entweder "Frachtkult" -Programmierung (dh anderer Code verwendet es, also verwenden wir es weiterhin, nur weil) oder in VB.NET, um die Tatsache zu umgehen, dass die Sprache ist Groß- und Kleinschreibung wird nicht berücksichtigt (z. B. Person oPerson = new Person, da Sie Person person = new Person Nicht verwenden können und Person p = new Person zu vage ist); Ich habe in diesem speziellen Fall auch das Präfix "the" oder "my" gesehen (wie in Person thePerson = new Person Oder dem hässlicheren Person myPerson = new Person).

Ich werde die nur Zeit hinzufügen, in der ich Ungarisch verwende, normalerweise für ASP.NET-Steuerelemente, und das ist wirklich eine Frage der Wahl. Ich finde es sehr hässlich, TextBoxCustomerName oder CustomerNameTextBox gegen das einfachere txtCustomerName einzugeben, aber selbst das fühlt sich "schmutzig" an. Ich bin der Meinung, dass eine Namenskonvention für Steuerelemente verwendet werden sollte, da es mehrere Steuerelemente geben kann, die dieselben Daten anzeigen.

15
Wayne Molina

Ich werde mich nur auf SQL Server konzentrieren, da Sie es erwähnt haben. Ich sehe keinen Grund, 'tbl' vor einen Tisch zu stellen. Sie können sich einfach einen beliebigen tSQL-Code ansehen und eine Tabelle anhand ihrer Verwendung unterscheiden. Sie würden niemals Select from stored_procedure. Oder Select from table(with_param) wie eine UDF oder Execute tblTableOrViewName Wie eine gespeicherte Prozedur.

Tabellen könnten mit einer Ansicht verwechselt werden, aber wenn es darum geht, wie sie verwendet werden; Es gibt keinen Unterschied. Worum geht es also? Die ungarische Notation erspart Ihnen möglicherweise die Zeit, sie in SSMS nachzuschlagen (unter Tabelle oder Ansichten?), Aber das war es auch schon.

Variablen können ein Problem darstellen, müssen jedoch deklariert werden. Wie weit von Ihrer Deklarationsanweisung entfernt planen Sie die Verwendung einer Variablen? Das Scrollen einiger Zeilen sollte keine große Sache sein, es sei denn, Sie schreiben sehr lange Prozeduren. Es kann eine gute Idee sein, den langen Code ein wenig aufzubrechen.

Was Sie beschreiben, ist ein Schmerz, aber die ungarische Notationslösung löst das Problem nicht wirklich. Sie können sich den Code einer anderen Person ansehen und feststellen, dass der Variablentyp möglicherweise geändert wird, was nun eine Änderung des Variablennamens erfordert. Nur noch eine Sache zu vergessen. Und wenn ich ein VarChar verwende, müssen Sie sich trotzdem die Anweisung declare ansehen, um die Größe zu ermitteln. Beschreibende Namen werden Sie wahrscheinlich weiter bringen. @PayPeriodStartDate erklärt sich so ziemlich von selbst.

13
JeffO

Für mich ist die ungarische Notation ein Problem, um ein nicht ausreichend leistungsfähiges Typensystem zu umgehen. In Sprachen, in denen Sie Ihre eigenen Typen definieren können, ist es relativ trivial, einen neuen Typ zu erstellen, der das erwartete Verhalten codiert. In Joel Spolskys Schimpfen über die ungarische Notation gibt er ein Beispiel für die Verwendung, um mögliche XSS-Angriffe zu erkennen, indem er angibt, dass eine Variable oder Funktion entweder unsicher (uns) oder sicher (n) ist, die visuelle Überprüfung jedoch weiterhin vom Programmierer abhängt. Wenn Sie stattdessen ein erweiterbares Typsystem haben, können Sie einfach zwei neue Typen erstellen, UnsafeString und SafeString, und diese dann entsprechend verwenden. Als Bonus wird die Art der Codierung wie folgt:

SafeString encode(UnsafeString)

wenn Sie nicht auf die Interna von UnsafeString zugreifen oder andere Konvertierungsfunktionen verwenden, können Sie nur von einem UnsafeString zu einem SafeString wechseln. Wenn alle Ihre Ausgabefunktionen nur Instanzen von SafeString verwenden, ist es unmöglich, eine nicht maskierte Zeichenfolge auszugeben [ohne Spielereien mit Konvertierungen wie StringToSafeString (someUnsafeString.ToString ())].

Es sollte offensichtlich sein, warum es besser ist, dem Typsystem die Überprüfung Ihres Codes zu ermöglichen, als dies von Hand zu versuchen, oder in diesem Fall vielleicht ein Auge zu haben.

In einer Sprache wie C ist natürlich klar, dass ein int ein int ein int ist, und Sie können nicht viel dagegen tun. Sie könnten immer Spiele mit Strukturen spielen, aber es ist fraglich, ob dies eine Verbesserung ist oder nicht.

Was die andere Interpretation der ungarischen Notation betrifft, so ist I.E. Das Präfixieren des Variablentyps ist einfach nur dumm und fördert faule Praktiken wie das Benennen von Variablen uivxwFoo anstelle von etwas Sinnvollem wie countOfPeople.

6
Orclev

Eine andere Sache, die Sie hinzufügen sollten, ist, welche Abkürzungen würden Sie für ein ganzes Framework wie .NET verwenden? Ja, es ist so einfach, sich daran zu erinnern, dass btn eine Schaltfläche und txt ein Textfeld darstellt. Was haben Sie jedoch für so etwas wie StringBuilder vor? strbld? Was ist mit CompositeWebControl? Verwenden Sie so etwas:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Eine der Ineffizienzen der ungarischen Notation war, dass sich durch immer größere Frameworks nicht nur ein zusätzlicher Nutzen, sondern auch eine größere Komplexität für Entwickler herausstellte, da sie nun die nicht standardmäßigen Präfixe immer mehr lernen mussten.

6
Saeed Neamati

Die ungarische Notation ist in einer statisch typisierten Sprache fast völlig nutzlos. Es ist eine grundlegende Funktion IDE), um den Typ einer Variablen anzuzeigen, indem Sie mit der Maus darüber fahren, oder auf andere Weise. Außerdem können Sie den Typ erkennen, indem Sie ein paar Zeilen nach oben schauen, wo er war deklariert, wenn es keine Typinferenz gibt. Der springende Punkt bei der Typinferenz ist, dass das Rauschen des Typs nicht überall wiederholt wird. Daher wird die ungarische Notation in Sprachen mit Typinferenz normalerweise als eine schlechte Sache angesehen.

In dynamisch getippten Sprachen kann es manchmal helfen, aber für mich fühlt es sich unidiomatisch an. Sie haben bereits aufgegeben, dass Ihre Funktionen auf exakte Domänen/Codomänen beschränkt sind. Wenn alle Ihre Variablen in ungarischer Notation benannt sind, reproduzieren Sie nur, was Ihnen ein Typsystem gegeben hätte. Wie drückt man eine polymorphe Variable aus, die eine Ganzzahl oder eine Zeichenfolge in ungarischer Notation sein kann? "IntStringX"? "IntOrStringX"? Der einzige Ort, an dem ich jemals die ungarische Notation verwendet habe, war der Assembly-Code, weil ich versucht habe, das zurückzubekommen, was ich bekommen würde, wenn ich ein Typsystem hätte, und es war das erste, was ich jemals codiert habe.

Wie auch immer, es ist mir egal, wie die Leute ihre Variablen nennen, der Code wird wahrscheinlich immer noch genauso unverständlich sein. Entwickler verschwenden viel zu viel Zeit mit Stil- und Variablennamen, und am Ende des Tages erhalten Sie immer noch eine Menge Bibliotheken mit völlig unterschiedlichen Konventionen in Ihrer Sprache. Ich entwickle eine symbolische (dh nicht textbasierte) Sprache, in der es keine Variablennamen, nur eindeutige Bezeichner und vorgeschlagene Namen für Variablen gibt (aber die meisten Variablen haben immer noch keinen vorgeschlagenen Namen, weil dort existiert einfach nicht) ein vernünftiger Name für sie); Wenn Sie nicht vertrauenswürdigen Code prüfen, können Sie sich nicht auf Variablennamen verlassen.

4
Longpoke

Wie in einem solchen Fall üblich, werde ich eine Antwort veröffentlichen, bevor ich die Antworten anderer Teilnehmer lese.

Ich sehe drei "Fehler" in Ihrer Vision:

1) Wenn Sie den Typ einer Variablen/eines Parameters/eines Attributs/einer Spalte kennen möchten, können Sie mit der Maus darüber klicken oder darauf klicken, und es wird in der modernsten IDE angezeigt. Ich weiß nicht, welche Tools Sie verwenden, aber als ich das letzte Mal gezwungen war, in einer Umgebung zu arbeiten, in der diese Funktion nicht verfügbar war, war die Sprache COBOL, hoppla, nein, es war Fortran und mein Chef Ich habe nicht verstanden, warum ich gegangen bin.

2/Typen können sich während des Entwicklungszyklus ändern. Eine 32-Bit-Ganzzahl kann aus guten Gründen, die zu Beginn des Projekts nicht erkannt wurden, irgendwann zu einer 64-Bit-Ganzzahl werden. Das Umbenennen von intX in longX oder das Belassen eines Namens, der auf den falschen Typ verweist, ist schlechtes Karma.

3) Was Sie verlangen, ist tatsächlich eine Redundanz. Redundanz ist nicht sehr gutes Designmuster oder Gewohnheit. Sogar Menschen zögern zu viel Redundanz. Sogar Menschen zögern zu viel Redundanz.

3
Oqaqiq

Ich glaube, dass es ein Symptom ist, dringend Ungarisch zu brauchen.
Ein Symptom für zu viele globale Variablen ... oder für Funktionen zu lang, um erhalten zu werden.

Wenn Ihre Variablendefinition normalerweise nicht in Sicht ist, haben Sie Probleme.
Und wenn Ihre Funktionen nicht einigen denkwürdigen Konventionen folgen, gibt es wieder große Probleme.

Das ist ... so ziemlich der Grund, warum viele Arbeitsplätze es vermasseln, nehme ich an.

Es entstand am Sprachen das benötigt es.
Zu Zeiten von globale Variablen bonanza. (mangels Alternativen)
Es hat uns gut gedient.

Die einzige wirkliche Verwendung, die wir heute dafür haben, ist die Joel Spolsky one .
Um einige bestimmte Attribute der Variablen zu verfolgen, wie ihre Sicherheit.

( z. B. “Hat die Variable safeFoobar grünes Licht, um in eine SQL-Abfrage eingefügt zu werden?
- Wie es safe heißt, ja ”)

In einigen anderen Antworten ging es um Editorfunktionen, mit denen Sie den Typ einer Variablen beim Bewegen des Mauszeigers erkennen konnten. Meiner Ansicht nach sind auch diese irgendwie problematisch für die Code-Vernunft. Ich glaube, sie waren nur für das Refactoring gedacht, ebenso wie viele andere Funktionen (wie das Falten von Funktionen) und sollten nicht für neuen Code verwendet werden.

3
ZJR

Ich denke, die Gründe, die ungarische Notation nicht zu verwenden, wurden von anderen Postern gut abgedeckt. Ich stimme ihren Kommentaren zu.

Bei Datenbanken verwende ich die ungarische Notation für DDL-Objekte, die im Code selten verwendet werden, aber ansonsten in Namespaces kollidieren würden. Dies hängt hauptsächlich davon ab, dass Indizes und benannte Einschränkungen ihrem Typ vorangestellt werden (PK, UK, FK und IN). Verwenden Sie eine konsistente Methode, um diese Objekte zu benennen, und Sie sollten in der Lage sein, einige Überprüfungen durchzuführen, indem Sie die Metadaten abfragen.

2
BillThor

Nehmen wir an, wir haben eine Methode wie diese (in C #):

int GetCustomerCount()
{
    // some code
}

Jetzt im Code nennen wir es so:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

Das int sagt uns nicht viel. Die bloße Tatsache, dass etwas ein Int ist, sagt uns nicht, was darin enthalten ist. Nehmen wir stattdessen an, wir nennen es stattdessen so:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Jetzt können wir sehen, was der Zweck der Variablen ist. Wäre es wichtig, wenn wir wissen, dass es ein Int ist?

Der ursprüngliche Zweck des Ungarischen war es jedoch, Sie so etwas tun zu lassen:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

Dies ist in Ordnung, solange Sie wissen, wofür c steht. Aber Sie müssten eine Standardtabelle mit Präfixen haben, und jeder müsste sie kennen, und alle neuen Leute müssten sie lernen, um Ihren Code zu verstehen. Während customerCount oder countOfCustomers auf den ersten Blick ziemlich offensichtlich ist.

Ungarisch hatte einen Zweck in VB vor Option Strict On existierte, weil in VB6 und früheren (und in VB .NET mit Option Strict Off) VB würde Typen erzwingen, also könnten Sie dies tun:

Dim someText As String = "5"
customerCount = customerCount + someText

Das ist schlecht, aber der Compiler würde es Ihnen nicht sagen. Wenn Sie also Ungarisch verwenden, haben Sie zumindest einen Indikator dafür, was passiert ist:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

In .NET ist dies bei statischer Typisierung nicht erforderlich. Und Ungarisch wurde zu oft als Ersatz für eine gute Benennung verwendet. Vergessen Sie Ungarisch und wählen Sie stattdessen gute Namen.

1
Kyralessa

der Grund, warum dies vermieden wird, liegt in ungarischen Systemen, die gegen DRY (das Präfix ist genau der Typ, den der Compiler und (ein gutes) IDE ableiten kann) verstoßen.)

apps ungarisch O.T.O.H. Präfixe mit dem se der Variablen (d. h. scrxMouse ist eine x-Koordinate auf dem Bildschirm. Dies kann ein int-, short-, long- oder sogar ein benutzerdefinierter Typ sein (typedefs ermöglicht es Ihnen sogar, ihn einfach zu ändern)).

das Missverständnis von Systemen hat Ungarisch als Best Practice zerstört

1
ratchet freak

Der einzige Ort, an dem ich immer noch regelmäßig entweder ungarische oder analoge Suffixe verwende, ist in Kontexten, in denen dieselben semantischen Daten in zwei verschiedenen Formen vorliegen, wie z. B. Datenkonvertierung. Dies kann in Fällen der Fall sein, in denen mehrere Maßeinheiten vorhanden sind oder in denen mehrere Formen vorhanden sind (z. B. Zeichenfolge "123" und Ganzzahl 123).

Ich finde die hier angegebenen Gründe, warum ich es nicht benutze, zwingend, anderen nicht Ungarisch aufzuzwingen, sondern nur leicht suggestiv, um sich für Ihre eigene Praxis zu entscheiden.

Der Quellcode eines Programms ist eine eigenständige Benutzeroberfläche , die dem Betreuer Algorithmen und Metadaten anzeigt - und Redundanz in Benutzeroberflächen ist eine Tugend, keine Sünde . Sehen Sie sich z. B. die Bilder in " Das Design alltäglicher Dinge " an und sehen Sie sich die Türen mit der Aufschrift "Push" an, die so aussehen, als würden Sie sie ziehen, und die Bierzapfstellen, die die Bediener auf das wichtige Atomwaffen gehackt haben Reaktorsteuerungen, weil irgendwie "in der IDE über ihnen schweben" nicht gut genug war.

Das "nur in einer IDE schweben" ist kein Grund, kein Ungarisch zu verwenden - nur ein Grund einige Leute finden es vielleicht nicht nützlich. Ihr Kilometerstand kann abweichen.

Die Idee, dass Ungarisch einen erheblichen Wartungsaufwand verursacht, wenn sich Variablentypen ändern, ist albern - wie oft ändern Sie Variablentypen? Außerdem ist das Umbenennen von Variablen einfach:

Verwenden Sie einfach die IDE, um alle Vorkommen umzubenennen. Gander, antwortet auf Goose

Wenn Ungarisch Ihnen wirklich hilft, schnell einen Code zu finden und ihn zuverlässig zu pflegen, verwenden Sie ihn. Wenn nicht, nicht. Wenn andere Leute Ihnen sagen, dass Sie in Bezug auf Ihre eigenen Erfahrungen falsch liegen, würde ich vorschlagen, dass sie wahrscheinlich irrtümlich sind.

1
Ed Staub

Ich habe viele gute Argumente dagegen gefunden, aber eines, das ich nicht gesehen habe: Ergonomie.

Früher, als Sie nur string, int, bool und float hatten, wären die Zeichen sibf ausreichend gewesen. Aber mit string + short beginnen die Probleme. Verwenden Sie den gesamten Namen für das Präfix oder str_name für die Zeichenfolge? (Während Namen fast immer Zeichenfolgen sind - nicht wahr?) Was ist mit einer Straßenklasse? Namen werden immer länger, und selbst wenn Sie CamelCase verwenden, ist es schwer zu sagen, wo das Typpräfix endet und wo der Variablenname beginnt.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

Okay - Sie könnten Unterstreichungen verwenden, wenn Sie sie nicht bereits für etwas anderes verwenden, oder CamelCase verwenden, wenn Sie so lange Unterstreichungen verwendet haben:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

Es ist monströs und wenn Sie es konsequent tun, werden Sie haben

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

Entweder verwenden Sie nutzlose Präfixe für triviale Fälle wie Schleifenvariablen oder count. Wann haben Sie kürzlich einen Short oder einen Long für einen Zähler verwendet? Wenn Sie Ausnahmen machen, verlieren Sie oft Zeit und denken darüber nach, ob Sie ein Präfix benötigen oder nicht.

Wenn Sie viele Variablen haben, werden diese normalerweise in einem Objektbrowser gruppiert, der Teil Ihrer IDE ist. Wenn nun 40% mit i_ für int und 40% mit s_ für string beginnen und alphabetisch sortiert sind, ist es schwierig, den signifikanten Teil des Namens zu finden.

1
user unknown