Ungarische Notation

Ungarische Notation ist eine Bezeichner-Namengeben-Tagung in der Computerprogrammierung, in der der Name einer Variable oder Funktion seinen Typ oder beabsichtigten Gebrauch anzeigt. Es gibt zwei Typen der ungarischen Notation: Ungarische Systemnotation und ungarische Anwendungsnotation.

Ungarische Notation wurde entworfen, um sprachunabhängig zu sein, und sein erster Hauptgebrauch mit der BCPL Programmiersprache gefunden. Weil BCPL keine Datentypen außer dem Maschinenwort hat, hilft nichts auf der Sprache selbst einem Programmierer, sich an die Typen von Variablen zu erinnern. Ungarische Notation hat zum Ziel, das durch das Versorgen des Programmierers mit ausführlichen Kenntnissen des Datentyps jeder Variable zu beheben.

In der ungarischen Notation fängt ein Variablenname mit einer Gruppe von Kleinbuchstaben an, die Gedächtniskunst für den Typ oder Zweck dieser Variable sind, die von beliebigem Namen gefolgt ist, den der Programmierer gewählt hat; dieser letzte Teil ist manchmal als der Vorname bemerkenswert. Der erste Charakter des Vornamens kann kapitalisiert werden, um es von den Typ-Hinweisen zu trennen (sieh auch CamelCase). Sonst zeigt der Fall dieses Charakters Spielraum an.

Geschichte

Die ursprüngliche ungarische Notation, die jetzt Anwendungsungarn genannt würde, wurde von Charles Simonyi, einem Programmierer erfunden, der an Xerox PARC um 1972-1981 gearbeitet hat, und wer später Hauptarchitekt an Microsoft geworden ist. Es kann aus dem früheren Grundsatz abgeleitet worden sein, den ersten Brief eines Variablennamens zu verwenden, um seinen Typ — zum Beispiel zu setzen, Variablen, deren Namen mit Briefen I durch N in FORTRAN angefangen haben, waren ganze Zahlen standardmäßig.

Die Notation ist eine Verweisung auf die Nation von Simonyi des Ursprungs; die Namen der ungarischen Leute werden im Vergleich zu den meisten anderen europäischen Namen "umgekehrt"; der Familienname geht dem Vornamen voran. Zum Beispiel war der anglisierte Name "Charles Simonyi" in Ungarisch ursprünglich "Simonyi Charles" (Simonyi Károly in Ungarisch). Ebenso geht der Typ-Name dem "Vornamen" in der ungarischen Notation aber nicht dem natürlicheren, zu den meisten Europäern, Plausch "Typ das letzte" Namengeben des Stils z.B aPoint und lastPoint voran. Dieser letzte Namengeben-Stil war an Xerox PARC während der Amtszeit von Simonyi dort am üblichsten.

Der Name Anwendungsungar wurde ins Leben gerufen, seitdem die Tagung in der Anwendungsabteilung des Microsofts verwendet wurde. Systemungar hat sich später in der Windows-Entwicklungsmannschaft von Microsoft entwickelt. Das auf Präfixe verwiesene Papier von Simonyi hat gepflegt, den "Typ" der Information anzuzeigen, die wird versorgt. Sein Vorschlag ist größtenteils mit schmückenden Bezeichner-Namen beschäftigt gewesen, die auf der semantischen Information dessen gestützt sind, was sie (mit anderen Worten, der Zweck der Variable), im Einklang stehend mit dem Anwendungsungarn versorgen. Jedoch waren seine Vorschläge davon nicht völlig verschieden, was bekannt als Systemungar geworden ist, weil einige seiner angedeuteten Präfixe wenig oder keine semantische Information enthalten (sieh unten für Beispiele).

Die ungarische Begriff-Notation ist für viele Menschen denkwürdig, weil die Reihen von unaussprechlichen Konsonanten vage der konsonant-reichen Rechtschreibung von einigen osteuropäischen Sprachen ähneln, ungeachtet der Tatsache dass Ungarisch eine Sprache von Uralic ist, und verschieden von slawischen Sprachen an Vokalen ziemlich reich ist. Zum Beispiel ist das nullbegrenzte Schnur-Präfix "sz" auch ein Brief im ungarischen Alphabet.

Systeme gegen den Anwendungsungarn

Wo sich Systemnotation und Notation von Apps unterscheiden, ist im Zweck der Präfixe.

In der ungarischen Systemnotation verschlüsselt das Präfix den wirklichen Datentyp der Variable. Zum Beispiel:

  • : Variable ist eine lange ganze Zahl ;
  • : Variable ist eine 'Reihe von nicht unterzeichneten ganzen 8-Bit-Zahlen ;
  • : Variable ist eine nullbegrenzte Schnur ; das war eines der ursprünglichen angedeuteten Präfixe von Simonyi.
  • : die Funktion mit einem Byte-Wert gibt Code zurück.

Ungarische Anwendungsnotation müht sich, den logischen Datentyp aber nicht den physischen Datentyp zu verschlüsseln; auf diese Weise gibt es einen Hinweis betreffs, was der Zweck der Variable ist, oder was es vertritt.

  • : Variable vertritt eine Reihe ;
  • : Variable vertritt eine unsichere Schnur , der "sterilisiert" werden muss, bevor sie verwendet wird (z.B sehen Codeeinspritzung und Quer-Seite scripting für Beispiele von Angriffen, die durch das Verwenden rohen Benutzereingangs verursacht werden können)
  • : Variable vertritt eine Schnur , den Namen enthaltend, aber gibt nicht an, wie diese Schnur durchgeführt wird.

Die meisten, aber nicht alle, der Präfixe, die Simonyi vorgeschlagen hat, ist in der Natur semantisch. Der folgende ist Beispiele vom ursprünglichen Papier:

  • ist ein Zeigestock zu einem anderen Typ X; das enthält sehr wenig semantische Information.
  • ist ein Präfix-Bedeutungsunterschied zwischen zwei Werten; zum Beispiel könnte dY eine Entfernung entlang der Y-Achse eines Graphen vertreten, während eine Variable gerade gerufen hat, könnte y eine absolute Position sein. Das ist in der Natur völlig semantisch.
  • ist eine Null - oder nullbegrenzte Schnur. In C enthält das etwas semantische Information, weil es nicht klar ist, ob eine Variable des Typs char* ein Zeigestock zu einem einzelnen Charakter, einer Reihe von Charakteren oder einer nullbegrenzten Schnur ist.
  • kennzeichnet eine Variable, die ein Wort ist. Das enthält im Wesentlichen keine semantische Information überhaupt, und würde wahrscheinlich als Systemungar betrachtet.
  • kennzeichnet ein Byte, das im Gegensatz zu w semantische Information haben könnte, weil in C der einzige byte-große Datentyp die Rotforelle ist, so werden diese manchmal verwendet, um numerische Werte zu halten. Dieses Präfix könnte Zweideutigkeit dazwischen klären, ob die Variable einen Wert hält, der als ein Brief (oder mehr allgemein ein Charakter) oder eine Zahl behandelt werden sollte.

Während die Notation immer anfängliche Kleinbuchstaben als Gedächtniskunst verwendet, schreibt sie die Gedächtniskunst selbst nicht vor. Es gibt mehrere weit verwendete Vereinbarung (sieh Beispiele unten), aber jeder Satz von Briefen kann verwendet werden, so lange sie innerhalb eines gegebenen Körpers des Codes entsprechen.

Es ist für den Code mit der ungarischen Anwendungsnotation möglich, um manchmal Systemungarisch zu enthalten, wenn man Variablen beschreibt, die allein in Bezug auf ihren Typ definiert werden.

Beziehung zu sigils

Auf einigen Programmiersprachen hat eine ähnliche Notation jetzt gerufen sigils wird in die Sprache eingebaut und durch den Bearbeiter beachtet. Zum Beispiel, im GRUNDLEGENDEN, nennt eine Schnur und nennt eine ganze Zahl. Sigils haben die bemerkenswerten Vorteile gegenüber der ungarischen Notation, dass sie implizit den Typ der Variable ohne Bedürfnis nach der überflüssigen Behauptung definieren, und auch durch den Bearbeiter überprüft werden, Weglassung und Missbrauch verhindernd.

Andererseits sind solche Systeme in der Praxis weniger flexibel als ungarische Notation, normalerweise nur einige verschiedene Typen definierend - der Mangel an entsprechenden easy-remember Symbolen versperrt umfassenderen Gebrauch.

Beispiele

  • : boolean
  • : Rotforelle
  • : Zählung von Sachen
  • : doppeltes Wort (Systeme)
  • : boolean (Fahne)
  • : ganze Zahl (Systeme) oder Zählung (Anwendung)
  • : ganze Zahl (Systeme) oder Index (Anwendung)
  • : Schwimmpunkt
  • : doppelt (Systeme)
  • : Zeigestock
  • : Reihe oder Reihe
  • : nullbegrenzte Schnur
  • : nicht unterzeichnete ganze 32-Bit-Zahl (Systeme)
  • : Uhr-Zeitstruktur
  • : fungieren Sie nennen

Der Gedächtniskunst für Zeigestöcke und Reihe, die nicht wirkliche Datentypen ist, wird gewöhnlich vom Typ des Datenelements selbst gefolgt:

  • : Zeigestock zur nullbegrenzten Schnur
  • : die Reihe des Schwimmpunkts schätzt
  • : Reihe von nicht unterzeichneten lang (Systeme)

Während ungarische Notation auf jede Programmiersprache und Umgebung angewandt werden kann, wurde es von Microsoft für den Gebrauch mit der c Sprache insbesondere für Windows von Microsoft weit angenommen, und sein Gebrauch bleibt größtenteils beschränkt zu diesem Gebiet. Insbesondere der Gebrauch der ungarischen Notation wurde durch die "Programmierung von Charles Petzold von Windows", das Original (und für viele Leser, das endgültige) Buch auf der Windows-API-Programmierung weit bekehrt. So sind viele allgemein gesehene Konstruktionen der ungarischen Notation zu Windows spezifisch:

  • Für Programmierer, die Windows-Programmierung in C wahrscheinlich erfahren haben, sind die denkwürdigsten Beispiele (Wortgröße-Parameter) und (Parameter der langen ganzen Zahl) für WindowProc Funktion.
  • : behandeln Sie zu einem Fenster
  • : langer Zeigestock zu einer nullbegrenzten Schnur

Die Notation wird manchmal in C ++ erweitert, um das Spielraum einer Variable einzuschließen, die durch ein Unterstreichen getrennt ist. Diese Erweiterung wird häufig auch ohne die ungarische Typ-Spezifizierung verwendet:

  • : Mitglied eines globalen namespace, ganze Zahl
  • : Mitglied einer Struktur/Klasse, ganze Zahl
  • : Mitglied einer Struktur/Klasse
  • : statisches Mitglied einer Klasse

Vorteile

(Einige von diesen gelten für den Systemungarn nur.)

Unterstützer behaupten, dass die Vorteile der ungarischen Notation einschließen:

  • Der variable Typ kann von seinem Namen gesehen werden
  • Der Typ des durch eine Funktion zurückgegebenen Werts wird ohne lookup (d. h. das Suchen nach Funktionsdefinitionen in anderen Dateien, z.B ".h" Kopfball-Dateien, usw.) bestimmt
  • Die Formatierung von Variablennamen kann einige Aspekte des Codewiederfactorings vereinfachen (während sie einige Aspekte mehr fehlbar macht).
  • Vielfache Variablen mit der ähnlichen Semantik können in einem Block des Codes verwendet werden: dwWidth, iWidth, fWidth, dWidth
  • Variablennamen können leicht sein, sich davon zu erinnern, gerade ihre Typen zu wissen.
  • Es führt zu konsequenteren Variablennamen
  • Unpassendes Typ-Gussteil und Operationen mit unvereinbaren Typen können leicht entdeckt werden, während man Code liest
  • Nützlich mit Schnur-basierten Sprachen, wo numerics Schnuren (Tcl zum Beispiel) sind
  • Im Anwendungsungarn schützt der Variablenname vor dem Verwenden davon in einer unpassenden Operation mit demselben Datentyp durch das Bilden des Fehlers offensichtlich als in:

:: heightWindow = window.getWidth

Wenn
  • man auf einer Sprache programmiert, die das dynamische Schreiben verwendet, oder das wird völlig ungetippt, die Dekorationen, die sich auf Typen beziehen, hören auf, überflüssig zu sein. Solche Sprachen schließen normalerweise Behauptungen von Typen nicht ein (oder machen sie fakultativ), so sind die einzigen Quellen dessen, was Typen erlaubt wird, die Namen selbst, Dokumentation wie Anmerkungen, und indem sie den Code lesen, um zu verstehen, was es tut. Auf diesen Sprachen, einschließlich einer Anzeige des Typs einer Variable kann dem Programmierer helfen. Wie oben erwähnt hat sich ungarische Notation auf solch einer Sprache (BCPL) ausgebreitet.
  • In komplizierten Programmen mit vielen globalen Gegenständen (VB/Delphi Formen), eine grundlegende Präfix-Notation habend, kann die Arbeit erleichtern, den Bestandteil innerhalb des Redakteurs zu finden. Das Schreiben und Drücken von Ursachen der Redakteur, um eine Liste von Knopf-Gegenständen knallen zu lassen.
  • Das Anwenden ungarischer Notation auf eine schmalere Weise, wie Verwendung nur für Mitglied-Variablen hilft dem Vermeiden der Namengeben-Kollision.

Nachteile

Die meisten Argumente gegen die ungarische Notation sind gegen die ungarische Systemnotation, nicht ungarische Anwendungsnotation. Einige potenzielle Probleme sind:

  • Die ungarische Notation ist überflüssig, wenn Datentypprüfung durch den Bearbeiter getan wird. Bearbeiter für Sprachen, die Datentypprüfung zur Verfügung stellen, stellen sicher, dass der Gebrauch einer Variable mit seinem Typ automatisch im Einklang stehend ist; Kontrollen sind nach Augenmaß überflüssig und dem menschlichen Fehler unterworfen.
  • Alle modernen einheitlichen Entwicklungsumgebungen zeigen variable Typen auf Verlangen, und automatisch Fahne-Operationen, die unvereinbare Typen verwenden, die Notation größtenteils veraltet machend.
  • Ungarische Notation wird verwirrend, wenn sie verwendet wird, um mehrere Eigenschaften, als zu vertreten, in: Ein unveränderliches Bezugsargument, den Inhalt einer Datenbanksäule des Typs varchar (30) haltend, der ein Teil des primären Schlüssels des Tisches ist.
  • Es kann zu Widersprüchlichkeit führen, wenn Code modifiziert oder getragen wird. Wenn ein Typ einer Variable geändert wird, wird entweder die Dekoration auf dem Namen der Variable mit dem neuen Typ inkonsequent sein, oder der Name der Variable muss geändert werden. Ein besonders weithin bekanntes Beispiel ist der Standardtyp WPARAM und das Begleiten wParam formeller Parameter in vielen Windows-Systemfunktionsbehauptungen. Der 'w' tritt für 'Wort' ein, wo 'Wort' die heimische Wortgröße der Hardware-Architektur der Plattform ist. Es war ursprünglich ein 16-Bit-Typ auf 16-Bit-Wortarchitekturen, aber wurde zu 32 Bit auf 32-Bit-Wortarchitekturen geändert, oder 64-Bit-Typ auf 64-Bit-Wortarchitekturen in späteren Versionen des Betriebssystems, während er seinen eigentlichen Namen behält (ist sein wahrer zu Grunde liegender Typ UINT_PTR, d. h. eine nicht unterzeichnete ganze Zahl, die groß genug ist, um einen Zeigestock zu halten). Der semantische Scheinwiderstand, und folglich Programmierer-Verwirrung und Widersprüchlichkeit vom Plattform-zu-Plattform-, ist in der Annahme, dass 'w' für 16 Bit in jenen verschiedenen Umgebungen eintritt.
  • Den größten Teil der Zeit bedeutet das Wissen des Gebrauches einer Variable, seinen Typ zu wissen. Außerdem, wenn der Gebrauch einer Variable nicht bekannt ist, kann er nicht aus seinem Typ abgeleitet werden.
  • Ungarische Notation reduziert stark die Vorteile, an der Eigenschaft reiche Coderedakteure zu verwenden, die Vollziehung auf Variablennamen unterstützen, weil der Programmierer den ganzen Typ specifier zuerst eingeben muss.
  • Es macht Code weniger lesbar, durch das Verfinstern des Zwecks der Variable mit dem unnötigen Typ und den scoping Präfixen.
  • Die zusätzliche Typ-Information kann mehr beschreibende Namen ungenügend ersetzen. Z.B erzählt sDatabase dem Leser nicht, wie es ist. databaseName könnte ein mehr beschreibender Name sein.
  • Wenn Namen genug beschreibend sind, kann die zusätzliche Typ-Information überflüssig sein. Z.B ist Vorname eine Schnur am wahrscheinlichsten. So es nennend, fügt sFirstName nur Durcheinander zum Code hinzu.
  • Es ist härter, sich an die Namen zu erinnern.

Bemerkenswerte Meinungen

  • Linus Torvalds (gegen den Systemungarn):
  • Steve McConnell (für Ungarisch):
  • Bjarne Stroustrup (gegen den Systemungarn für C ++):
  • Joel Spolsky (für den Anwendungsungarn):
  • Tim Ottinger (gegen den Systemungarn):
  • Die Designrichtlinien des Microsofts halten Entwickler davon ab, ungarische Notation zu verwenden, wenn sie Namen für die Elemente in.NET Klassenbibliotheken wählen, obwohl es auf vorherigen Entwicklungsplattformen von Microsoft wie Visuelle Grundlegende 6 und früher üblich war. Diese Designrichtlinien sind auf der Namengeben-Vereinbarung für lokale Variablen innerhalb von Funktionen still.

Links


Xerox-Netzsysteme / Gelimer
Impressum & Datenschutz