Ungarische Notation - Hungarian notation

Die ungarische Notation ist eine Benennungskonvention für Bezeichner in der Computerprogrammierung , bei der der Name einer Variablen oder Funktion ihre Absicht oder Art angibt und in einigen Dialekten ihren Typ . Die ursprüngliche ungarische Notation verwendet Absicht oder Art in ihrer Namenskonvention und wird manchmal als Apps-Ungarisch bezeichnet, da sie in der Microsoft Apps-Abteilung bei der Entwicklung von Word, Excel und anderen Apps populär wurde. Als die Microsoft Windows-Abteilung die Namenskonvention übernahm, verwendete sie den tatsächlichen Datentyp für die Namensgebung, und diese Konvention wurde durch die Windows-API weit verbreitet; dies wird manchmal als Systemungarische Notation bezeichnet.

Simonyi : ...BCPL [hatte] einen einzigen Typ, der ein 16-Bit-Wort war... nicht, dass es wichtig wäre.

Booch : Es sei denn, Sie setzen die ungarische Notation fort.

Simonyi : Auf jeden Fall... wir sind auch später zu den getippten Sprachen übergegangen... Aber... wir würden uns einen Namen ansehen und ich würde dir genau viel darüber erzählen...

Die ungarische Notation wurde als sprachunabhängig konzipiert und fand ihren ersten großen Einsatz in der Programmiersprache BCPL . Da BCPL keine Datentypen anders als die Maschine hat Wort , nichts in der Sprache selbst hilft ein Programmierer Variablen Typen erinnern. Die ungarische Notation soll hier Abhilfe schaffen, indem sie dem Programmierer explizite Kenntnisse über den Datentyp jeder Variablen vermittelt.

In der ungarischen Notation, ein Variablenname beginnt mit einer Gruppe von Kleinbuchstaben, die Mnemonics für die Art oder den Zweck dieser Variablen, gefolgt von welchem Namen der Programmierer ausgewählt hat; dieser letzte Teil wird manchmal als Vorname unterschieden . Das erste Zeichen des Vornamens kann großgeschrieben werden, um ihn von den Typkennzeichen zu trennen (siehe auch CamelCase ). Andernfalls bezeichnet die Groß-/Kleinschreibung dieses Zeichens den Geltungsbereich.

Geschichte

Die ursprüngliche ungarische Notation, die jetzt Apps Ungarisch heißen würde, wurde von Charles Simonyi erfunden , einem Programmierer, der zwischen 1972 und 1981 bei Xerox PARC arbeitete und später Chefarchitekt bei Microsoft wurde .

Der Name der Notation ist ein Hinweis auf Simonyis Herkunftsland; Die Namen der ungarischen Leute sind im Vergleich zu den meisten anderen europäischen Namen "umgekehrt"; der Familienname steht vor dem Vornamen . Zum Beispiel war der anglisierte Name "Charles Simonyi" auf Ungarisch ursprünglich "Simonyi Károly". Auf die gleiche Weise steht der Typname in ungarischer Notation vor dem "Vornamen" und nicht dem Smalltalk- Namensstil "Typ zuletzt" (zB aPoint und lastPoint). Dieser letztgenannte Namensstil war bei Xerox PARC während Simonyis Amtszeit dort am häufigsten.

Der Name Apps Ungarisch wurde erfunden, da die Konvention in der Anwendungsabteilung von Microsoft verwendet wurde. Systems Ungarisch entwickelte später im Microsoft Windows- Entwicklungsteam. Simonyis Aufsatz bezog sich auf Präfixe, die verwendet wurden, um die "Art" der gespeicherten Informationen anzugeben. Sein Vorschlag befasste sich hauptsächlich mit der Dekoration von Bezeichnernamen basierend auf den semantischen Informationen dessen, was sie speichern (mit anderen Worten, dem Zweck der Variablen ), im Einklang mit Apps Ungarisch. Seine Vorschläge unterschieden sich jedoch nicht vollständig von dem, was als Systemungarisch bekannt wurde, da einige seiner vorgeschlagenen Präfixe wenig oder keine semantischen Informationen enthalten (siehe unten für Beispiele).

Systeme Ungarisch vs. Apps Ungarisch

Wo sich die Systemnotation und die Apps-Notation unterscheiden, liegt im Zweck der Präfixe.

In der ungarischen Systemnotation kodiert das Präfix den tatsächlichen Datentyp der Variablen. Zum Beispiel:

  • lAccountNum : Variable ist eine lange Ganzzahl ( "l");
  • arru8NumberList : Die Variable ist ein arr von ay u nsigned 8 -Bit ganzen Zahlen ( "arru8");
  • bReadLine(bPort,&arru8NumberList) : Funktion mit einem Byte-Wert-Rückgabecode.
  • strName : Variable stellt eine Zeichenfolge ( "str") dar, die den Namen enthält, gibt jedoch nicht an, wie diese Zeichenfolge implementiert wird.

Die ungarische Notation von Apps ist bestrebt, den logischen Datentyp und nicht den physischen Datentyp zu codieren. Auf diese Weise gibt es einen Hinweis auf den Zweck der Variablen oder was sie darstellt.

  • rwPosition : Variable repräsentiert eine Zeile ( "rw");
  • usName : Variable stellt eine unsichere Zeichenfolge ( "us") dar, die vor ihrer Verwendung "bereinigt" werden muss (z. B. siehe Code-Injection und Cross-Site-Scripting für Beispiele für Angriffe, die durch die Verwendung von rohen Benutzereingaben verursacht werden können)
  • szName : Die Variable ist ein Z ero-termini s tring ( "sz"); dies war eines der ursprünglich von Simonyi vorgeschlagenen Präfixe.

Die meisten, aber nicht alle der von Simonyi vorgeschlagenen Präfixe sind semantischer Natur. Für moderne Augen scheinen einige Präfixe physikalische Datentypen darzustellen, beispielsweise szfür Zeichenfolgen. Solche Präfixe waren jedoch immer noch semantisch, da Simonyi die ungarische Notation für Sprachen beabsichtigte, deren Typsysteme einige Datentypen, die moderne Sprachen als selbstverständlich betrachten, nicht unterscheiden konnten.

Im Folgenden sind Beispiele aus dem Originalpapier aufgeführt:

  • pXist ein Zeiger auf einen anderen Typ X ; dies enthält sehr wenige semantische Informationen.
  • dist ein Präfix, das den Unterschied zwischen zwei Werten bedeutet; zum Beispiel könnte dY eine Distanz entlang der Y-Achse eines Graphen darstellen, während eine Variable, die nur y genannt wird , eine absolute Position sein könnte. Dies ist rein semantischer Natur.
  • szist eine null- oder nullterminierte Zeichenfolge. In C enthält dies einige semantische Informationen, da nicht klar ist, ob eine Variable vom Typ char* ein Zeiger auf ein einzelnes Zeichen, ein Array von Zeichen oder ein nullterminierter String ist.
  • wmarkiert eine Variable, die ein Wort ist. Dies enthält im Wesentlichen überhaupt keine semantischen Informationen und würde wahrscheinlich als Systemungarisch angesehen werden.
  • bmarkiert ein Byte, das im Gegensatz zu w semantische Informationen enthalten kann, da in C der einzige Datentyp von Byte-Größe das char ist , daher werden diese manchmal verwendet, um numerische Werte aufzunehmen. Dieses Präfix kann die Mehrdeutigkeit beseitigen, ob die Variable einen Wert enthält, der als Zeichen oder als Zahl behandelt werden soll.

Während die Notation immer kleine Anfangsbuchstaben als Mnemonik verwendet, schreibt sie die Mnemonik selbst nicht vor. Es gibt mehrere weit verbreitete Konventionen (siehe Beispiele unten), aber es kann jeder beliebige Satz von Buchstaben verwendet werden, solange sie innerhalb eines bestimmten Codekörpers konsistent sind.

Es ist möglich, dass Code, der die ungarische Notation von Apps verwendet, manchmal Systemungarisch enthält, wenn Variablen beschrieben werden, die nur in Bezug auf ihren Typ definiert sind.

Beziehung zu Sigillen

In einigen Programmiersprachen ist eine ähnliche Notation, die jetzt Sigillen genannt wird, in die Sprache eingebaut und wird vom Compiler erzwungen. Zum Beispiel in einigen Formen von BASIC , name$Namen eine Zeichenfolge und count%Namen einer ganzen Zahl ist . Der Hauptunterschied zwischen ungarischer Notation und Sigille besteht darin, dass Sigille den Typ der Variablen in der Sprache deklarieren, während die ungarische Notation ein reines Benennungsschema ohne Auswirkungen auf die maschinelle Interpretation des Programmtexts ist.

Beispiele

  • bBusy : boolesch
  • chInitial : char
  • cApples : Anzahl der Artikel
  • dwLightYears : Doppelwort (System)
  • fBusy : Flagge (oder Float )
  • nSize : Ganzzahl (Systeme) oder Anzahl (Apps)
  • iSize : Ganzzahl (Systeme) oder Index (Apps)
  • fpPrice : Gleitkomma
  • dbPi : doppelt (Systeme)
  • pFoo : Zeiger
  • rgStudents : Array oder Bereich
  • szLastName : nullterminierte Zeichenfolge
  • u16Identifier : vorzeichenlose 16-Bit- Ganzzahl (Systeme)
  • u32Identifier : 32-Bit- Ganzzahl ohne Vorzeichen (Systeme)
  • stTime : Uhrzeitstruktur
  • fnFunction : Funktionsname

Auf die Mnemonik für Zeiger und Arrays , die keine eigentlichen Datentypen sind, folgt normalerweise der Typ des Datenelements selbst:

  • pszOwner : Zeiger auf nullterminierte Zeichenkette
  • rgfpBalances : Anordnung von Fließkommawerte
  • aulColors : Array von unsigned long (Systems)

Während die ungarische Notation auf jede Programmiersprache und Umgebung angewendet werden kann, wurde sie von Microsoft weithin für die Verwendung mit der C-Sprache übernommen, insbesondere für Microsoft Windows , und ihre Verwendung bleibt weitgehend auf diesen Bereich beschränkt. Insbesondere wurde die Verwendung der ungarischen Notation weit evangelisiert von Charles Petzold ‚s ‚Windows - Programmierung‘ , das Original (und für viele Leser, das endgültige) Buch über die Windows - API - Programmierung. Daher sind viele häufig verwendete Konstrukte der ungarischen Notation spezifisch für Windows:

  • Für Programmierer, die die Windows-Programmierung in C gelernt haben, sind die wahrscheinlich einprägsamsten Beispiele die wParam(Wortgrößen-Parameter) und lParam(Long-Integer-Parameter) für die WindowProc ()-Funktion.
  • hwndFoo : Griff zu einem Fenster
  • lpszBar : langer Zeiger auf einen nullterminierten String

Die Notation wird in C++ manchmal um den Gültigkeitsbereich einer Variablen erweitert, optional durch einen Unterstrich getrennt. Diese Erweiterung wird oft auch ohne die ungarische Typenbezeichnung verwendet:

  • g_nWheels : Mitglied eines globalen Namensraums, Integer
  • m_nWheels : Mitglied einer Struktur/Klasse, Integer
  • m_wheels, _wheels : Mitglied einer Struktur/Klasse
  • s_wheels : statisches Mitglied einer Klasse
  • c_wheels : statisches Mitglied einer Funktion

In JavaScript- Code, der jQuery verwendet , $wird häufig ein Präfix verwendet, um anzugeben, dass eine Variable ein jQuery-Objekt enthält (im Gegensatz zu einem einfachen DOM-Objekt oder einem anderen Wert).

Vorteile

(Einige davon gelten nur für Systems Ungarisch.)

Befürworter argumentieren, dass die Vorteile der ungarischen Notation umfassen:

  • Der Symboltyp ist an seinem Namen zu erkennen. Dies ist nützlich, wenn Sie den Code außerhalb einer integrierten Entwicklungsumgebung betrachten – wie bei einer Codeüberprüfung oder einem Ausdruck – oder wenn sich die Symboldeklaration von der Verwendungsstelle aus in einer anderen Datei befindet, z. B. einer Funktion.
  • In einer Sprache, die dynamische Typisierung verwendet oder nicht typisiert ist, sind die Verzierungen, die sich auf Typen beziehen, nicht mehr überflüssig. In solchen Sprachen werden Variablen normalerweise nicht so deklariert, dass sie einen bestimmten Datentyp enthalten. Der einzige Hinweis darauf, welche Operationen damit ausgeführt werden können, sind vom Programmierer gegebene Hinweise, wie ein Variablenbenennungsschema, Dokumentation und Kommentare. Wie oben erwähnt, wurde die ungarische Notation in einer solchen Sprache ( BCPL ) erweitert.
  • Die Formatierung von Variablennamen kann einige Aspekte des Code-Refactoring vereinfachen (während andere Aspekte fehleranfälliger machen).
  • In einem Codeblock können mehrere Variablen mit ähnlicher Semantik verwendet werden: dwWidth, iWidth, fWidth, dWidth.
  • Variablennamen kann man sich leicht merken, wenn man nur ihre Typen kennt.
  • Dies führt zu konsistenteren Variablennamen.
  • Ungeeignete Typumwandlungen und Operationen mit inkompatiblen Typen können beim Lesen von Code leicht erkannt werden.
  • In komplexen Programmen mit vielen globalen Objekten (VB/Delphi Forms) kann eine einfache Präfixnotation das Auffinden der Komponente im Editor erleichtern. Wenn Sie beispielsweise nach der Zeichenfolge btnsuchen, werden möglicherweise alle Button-Objekte gefunden.
  • Eine engere Anwendung der ungarischen Notation, z. B. nur für Elementvariablen , hilft, Namenskollisionen zu vermeiden .
  • Gedruckter Code ist für den Leser bei Datentypen, Typkonvertierungen, Zuweisungen, Kürzungen usw. klarer.

Nachteile

Die meisten Argumente gegen ungarische Notation sind gegen Systeme ungarische Notation, nicht Apps ungarische Notation. Einige mögliche Probleme sind:

  • Die ungarische Notation ist überflüssig, wenn der Compiler die Typprüfung durchführt. Compiler für Sprachen mit strikter Typprüfung wie Pascal stellen automatisch sicher, dass die Verwendung einer Variablen mit ihrem Typ übereinstimmt; Augenkontrollen sind überflüssig und unterliegen menschlichen Fehlern.
  • Die meisten modernen integrierten Entwicklungsumgebungen zeigen Variablentypen bei Bedarf an und kennzeichnen automatisch Operationen, die inkompatible Typen verwenden, wodurch die Notation weitgehend überflüssig wird.
  • Ungarischen Notation wird verwirrend , wenn es verwendet wird , mehrere Eigenschaften zu repräsentieren, wie in a_crszkvc30LastNameCol: einem konstanten Referenz Argument , um den Inhalt einer Haltedatenbankspalte vom Typ VARCHAR (30) , die Teil der Tabelle ist der Primärschlüssel .LastName
  • Es kann zu Inkonsistenzen führen, wenn Code geändert oder portiert wird. Wenn der Typ einer Variablen geändert wird, stimmt entweder die Dekoration des Variablennamens nicht mit dem neuen Typ überein oder der Name der Variablen muss geändert werden. Ein besonders bekanntes Beispiel ist der Standard - WPARAM - Typ und die WParam begleitenden formalen Parameter in vielen Windows - Systemfunktionsdeklarationen. Das „w“ steht für „Wort“, wobei „Wort“ die native Wortgröße der Hardwarearchitektur der Plattform ist. Es war ursprünglich ein 16-Bit-Typ auf 16-Bit-Wortarchitekturen, wurde jedoch in späteren Versionen des Betriebssystems in einen 32-Bit-Typ auf 32-Bit-Wortarchitekturen oder in einen 64-Bit-Typ auf 64-Bit-Wortarchitekturen geändert, während seine Funktion beibehalten wurde Originalname (der wahre zugrunde liegende Typ ist UINT_PTR, d. h. eine ganze Zahl ohne Vorzeichen, die groß genug ist, um einen Zeiger aufzunehmen). Die semantische Impedanz und damit die Verwirrung und Inkonsistenz des Programmierers von Plattform zu Plattform beruht auf der Annahme, dass 'w' in diesen unterschiedlichen Umgebungen für ein zwei Byte langes 16-Bit-Wort steht.
  • Meistens setzt die Kenntnis der Verwendung einer Variablen voraus, ihren Typ zu kennen. Wenn die Verwendung einer Variablen nicht bekannt ist, kann sie außerdem nicht aus ihrem Typ abgeleitet werden.
  • Die ungarische Notation reduziert die Vorteile der Verwendung von Code-Editoren, die die Vervollständigung von Variablennamen unterstützen, da der Programmierer zuerst den Typbezeichner eingeben muss, der eher mit anderen Variablen kollidiert als bei Verwendung anderer Namensschemata.
  • Es macht Code weniger lesbar, indem es den Zweck der Variablen mit Typ- und Bereichspräfixen verschleiert.
  • Die zusätzlichen Typinformationen können aussagekräftigere Namen nur unzureichend ersetzen. sDatabase sagt dem Leser zB 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. ZB ist firstName höchstwahrscheinlich ein String. Die Benennung sFirstName fügt dem Code nur Unordnung hinzu.
  • Es ist schwieriger, sich die Namen zu merken.
  • Mehrere Variablen mit unterschiedlicher Semantik können in einem Codeblock mit ähnlichen Namen verwendet werden: dwTmp, iTmp, fTmp, dTmp .
  • Das Platzieren von Datentyp- oder Absichtszeichenbezeichnern als Präfix zum Vornamen des Felds oder der Variablen untergräbt in einigen Programmierumgebungen die Möglichkeit, alphabetisch zu einem Feld- oder Variablennamen zu springen, wenn der Benutzer mit der Eingabe des Namens beginnt. FileMaker ist beispielsweise eine solche Programmierumgebung. Wenn Sie eine dieser Programmierumgebungen verwenden, kann es vorzuziehen sein, Vornamen stattdessen mit solchen identifizierenden Zeichen zu versehen.

Bemerkenswerte Meinungen

  • Robert Cecil Martin (gegen ungarische Notation und alle anderen Kodierungsformen):

    ... Heutzutage sind HN und andere Formen der Typcodierung nur noch Hindernisse. Sie erschweren es, den Namen oder Typ einer Variablen, Funktion, eines Members oder einer Klasse zu ändern. Sie erschweren das Lesen des Codes. Und sie schaffen die Möglichkeit, dass das Kodierungssystem den Leser in die Irre führt.

  • Linus Torvalds (gegen System Ungarisch):

    Den Typ einer Funktion in den Namen zu kodieren (sogenannte ungarische Notation) ist hirngeschädigt – der Compiler kennt die Typen sowieso und kann sie überprüfen, und es verwirrt den Programmierer nur.

  • Steve McConnell (für Apps Ungarisch):

    Obwohl die ungarische Namenskonvention nicht mehr weit verbreitet ist, hat der Grundgedanke, auf knappe, präzise Abkürzungen zu standardisieren, weiterhin Wert. Mit standardisierten Präfixen können Sie Typen genau überprüfen, wenn Sie abstrakte Datentypen verwenden, die Ihr Compiler nicht unbedingt überprüfen kann.

  • Bjarne Stroustrup (gegen Systemungarisch für C++):

    Nein, ich empfehle 'Ungarisch' nicht. Ich betrachte 'Ungarisch' (das Einbetten einer abgekürzten Version eines Typs in einen Variablennamen) als eine Technik, die in nicht typisierten Sprachen nützlich sein kann, aber für eine Sprache, die generische Programmierung und objektorientierte Programmierung unterstützt, völlig ungeeignet ist – beide betonen Auswahl von Operationen anhand des Typs und der Argumente (der Sprache oder der Laufzeitunterstützung bekannt). In diesem Fall verkompliziert und minimiert das „Einbauen des Typs eines Objekts in Namen“ einfach die Abstraktion.

  • Joel Spolsky (für Apps Ungarisch):

    Wenn Sie Simonyis Aufsatz genau lesen, hat er die gleiche Namenskonvention erreicht, die ich in meinem obigen Beispiel verwendet habe, wo wir entschieden haben, dass usdies eine unsichere Zeichenfolge sbedeutet und eine sichere Zeichenfolge bedeutet. Sie sind beide vom Typ string. Der Compiler hilft Ihnen nicht, wenn Sie einen dem anderen zuweisen, und Intellisense [ein intelligentes Codevervollständigungssystem ] wird Ihnen keine bupkis mitteilen . Aber sie unterscheiden sich semantisch. Sie müssen unterschiedlich interpretiert und behandelt werden und eine Art Konvertierungsfunktion muss aufgerufen werden, wenn Sie eine der anderen zuweisen oder einen Laufzeitfehler haben. Wenn du Glück hast. Apps Ungarisch hat immer noch einen enormen Wert, da es die Kollokation im Code erhöht, was das Lesen, Schreiben, Debuggen und Warten des Codes erleichtert und vor allem falscher Code falsch aussehen lässt.... (Systems Ungarisch) war ein subtiles, aber völliges Missverständnis von Simonyis Absicht und Praxis.

  • Die Designrichtlinien von Microsoft raten Entwicklern davon ab, die ungarische Systemnotation zu verwenden, wenn sie Namen für die Elemente in .NET-Klassenbibliotheken wählen, obwohl dies auf früheren Microsoft-Entwicklungsplattformen wie Visual Basic 6 und früher üblich war. Diese Designrichtlinien enthalten keine Angaben zu den Namenskonventionen für lokale Variablen innerhalb von Funktionen.

Siehe auch

Verweise

Externe Links