Diskussion:Ungarische Notation

message: Man sollte meinen, ein Kritikteil setzt sich kritisch mit einem Thema auseinander. Derzeit (10.05.2011) besteht dieser Teil lediglich aus einem einleitenden kritisch-negativen Halbsatz, gefolgt von Lobeshymnen. Wie 141.20.145.221 schon sagte, sollte wenigstens der Gedanke der Clean-Code Initiative erwähnt werden. Z.B. ein (zugegeben etwas salopp formulierter) Gedanke von Andreas Seebauer: "In der heutigen Zeit ist die Ungarische Notation absoluter Quatsch. Die IDE kennt den Typ, warum sollte man das in den Variablennamen integrieren?" Quelle: http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/ --87.181.173.215 14:03, 10. Mai 2011 (CEST)
replies: text: Generell ist der Kritikteil unpassend. Er hebt nur Vorteile hervor und basiert nicht auf Quellen. 141.20.145.221 12:35, 4. Jan. 2011 (CET)
thread_title:  Kritik 

message: Hallo!
Leider spiegelt die hier gegebene Beschreibung nicht die "wahre" Intention der UN wider.
Meine kurze Zusammenfassung:
Simonyis Absicht war nicht, den (technischen) Datentyp einer Variablen hervorzuheben, sondern deren Typ im Sinne von Art, also der semantischen Bedeutung der Variablen.  So kommt es auch, dass Integers, die zB Zeilen oder Spalten in einer Tabelle bezeichnen, den Präfix row bzw. col bekommen, auch wenn es rein technisch Ints sein, die man problemlos miteinanders addieren/subtrahieren/etc. kann -- sinnvoll ist das jedoch nicht, deshalb die UN.  Simonyis Ur-Version wird auch als Apps Hungarian bezeichnet, erst später wurde daraus aufgrund einer Microsoft-internen Missinterpretation des engl. Wortes type das heute geläufige System Hungarian, das viele praktische Seiten des Apps Hungarian nicht mehr aufweist.
Quellen:
*Joel on Software - Making Wrong Code Look Wrong - ein aktueller Blogentry dazu
*Meta-Programming: A Software Production Method.  Charles Simonyi, December 1976 (PhD Thesis)
*Charles Simonyi's explanation of Hungarian Notation
Was ist zu tun?!
Ich finde es äußerst wichtig, das in den Artikel einzuarbeiten, hab im Moment keine Zeit und bin auch relative Wikipedia-unerfahren (deshalb hab ich auch keinen Account :) -- trotzdem werde ich versuchen, mich in den nächsten 2 Wochen ran zu setzten, und es einzuarbeiten -- wenn mir jemand zuvorkommt, hätte ich auch nicht dagegen ;)
Schöne Grüße an alle WP-Autoren, ihr macht verdammt gute Arbeit :)
Fabian, 2005-05-11
echter Typ
Hallo, ich muss das hier einfach mal loswerden: Im Artikel steht ja jetzt schon, dass Simonyis Absicht war die "Art" der Variablen Hervorzuheben und nicht deren "Typ" (im C Sinne, d.h. eben nicht int, char, etc.).
Was ich mir schon seit Ewigkeiten denke: Das ist immer noch nicht toll. In einer Sprache wie C++ gibt es zunächst einmal "Identifier". Diese werden vom Programmierer praktisch frei gewählt (alles ist erlaubt außer keywords). Identifier können stehen für:
* Typen (z.B. uint32_t)
* Funktionen
* Lokale Variablen
* Globale Variablen
* Parameter von Funktionen/Methoden
* Klassennamen
* Methodennamen
* Variablennamen einer Klasse (members die keine Methoden sind).
Ich selber denke mir immer: Was ich WIRKLICH wissen will ist, für welche Sorte von Konstrukt ein Identifier verwendet wird. Man stelle sich folgenden C Einzeiler vor:
    x = y;
Was davon ist eine Variable/Funktion/Typ/Klassenbezeichner ? Das wäre viel einfacher zu lesen wenn es z.B. heisst:
    vX = vY;
Das würde mir nämlich sagen hier geht es um die Zuweisung von zwei lokalen Variablen, während
    vX = pY;
heißt: Einer lokalen Variable wird der Wert eines Parameters zugewiesen.
Der Witz dabei: So eine Art von Notation würde das Leben des Compilers ebenfalls VIEL einfacher machen; es ist (gerade bei C++) ein echtes Kunststück herauszufinden für was genau (Funktion, Klasse, Variable, Typ...) ein Identifier steht; gäbe es eine feste (erzwungene) Schreibweise, dann würde sich der Compiler VIEL leichter tun... 178.27.85.1 10:52, 19. Mai 2017 (CEST)
thread_title:  Die echte Ungarische Notation 

message: Wie sieht es mit der Anwendung der UN auf Funktionsnamen, Prozedurnamen, Klassennamen und was es sonst noch so gibt aus? Das fehlt in dem Artikel noch irgendwie ganz. Vieleicht könnten es auch noch ein paar mehr Beispiele sein, z.B. aus der WINAPI und in einer Gegenüberstellung, so macht es MS nach Systems Hungarian und so wäre es nach Apps Hungarian. Gruß --Jörg 17:06, 11. Nov. 2006 (CET)
thread_title:  UN für Funktionen usw. 

message: Der Name „ungarische Notation” hat nicht das geringste mit der ungarischen (oder auch asiatischen) Reihenfolge der Nach- und Vornamen zu tun.
Die Benennung ist wirklich nur darauf zurückzuführen, dass Simonyi selber Ungar ist. Obwohl er es nie erwähnt, es ist mehr als sicher, dass die kategorisierende Methodik seiner Muttersprache ihn bei der Erschaffung der Notation intuitiv beeinflusst habe; vgl. die Weblinks.
Gruß, Hägar Dünor --Keile mit Weile, sagt der Wikingär 15:27, 14. Apr. 2010 (CEST)
thread_title:  Der Ursprung des Namens 

message: Bei Informatik-Texten, die das Wort "physisch" benutzen oder wie hier sogar fortlaufend, kriege ich Pickel. Was ist denn bitte jeweils mit "physisch" gemeint!? Eines der schrägsten Unworte in der Informatik, noch vor "intelligent". --92.224.158.44 01:56, 13. Mär. 2013 (CET)
replies: text: Ich stimme dir zu, dass das Wort hier in höchst undurchsichtigen Zusammenhängen verwendet wird. Immerhin bin ich froh, dass es nicht auch noch „physikalisch“ heißt. Im amerikanischen Text des Artikels ist es geringfügig verständlicher, dort ist der Gegensatz „logical“ („was man sich darunter vorstellt“) und „physical“ („was es wirklich ist“). Die Terminologie klingt weniger schräg im Zusammenhang mit virtuellem Speicher, wo ein sehr großer Raum von logischen Adressen auf einen kleinen Bereich physischer Adressen abgebildet wird.  In Bezug auf die Datentypen ist die Terminologie aber wirklich ziemlich esoterisch, denn was soll „physisch“ sein an Entitäten, die keine physische Existenz haben, sondern bloß auf dem Papier/in der Vorstellung/im Rechner vorkommen. Mir fehlt momentan die Zeit, die Originalquellen nachzulesen, um Licht in dieses Dunkel zu bringen, aber dein Einwand ist in jedem Fall berechtigt. --Herbert Klaeren (Diskussion) 09:30, 13. Mär. 2013 (CET)
thread_title:  Physis 

message: "Lim (>Most) Mit Lim wird die Anzahl der Elemente in einem Array angegeben. Damit ist der Index mit dem Namen xxLim größer als das letzte Element und damit ungültig."
Das gilt nur für die Sprachen, deren erstes Element mit 0 indiziert wird - es gibt auch welche, bei denen 10 Elemente von 1-10 indiziert sind, selbst Arrays mit mit n Elementen, die von 0+m bis n+m zählen, sind möglich. Auf das "Anzahl=Max+1" wird hier mehrfach referenziert, bitte anpassen. --Mideal (Diskussion) 11:12, 15. Aug. 2017 (CEST)
thread_title:  Array-Größe vs. Limit 

message: Habe den POV-Bepper im Einleitungstext angebracht. Was da zum Datentyp gesagt wird, ist eine Meinung und gehört so in den Absatz "Kritik". Im Übrigen ist dieser Absatz (im Einleitungstext) eine ziemliche Unverfrorenheit gegenüber Generationen von Entwicklern und nicht zuletzt den Autoren des Artikels, die sich bspw. viel Mühe mit den Abschnitten 1.1 und 1.2 gegeben haben. Abgesehen davon fehlt hier auch jeglicher Beleg! --2003:E5:C3D5:14C0:D407:181:9A81:3666 13:09, 8. Jan. 2020 (CET)
thread_title:  Noch einmal POV 

message: In der Präfix-Tabelle ist zu lesen:
h   handle    Ein Zeiger auf einen Zeiger, also äquivalent zu pp. Fast immer wird h im Zusammenhang mit der Kommunikation mit dem Betriebssystem benutzt
Ein Handle ist (zumindest in der Unix und Windows-Programmierung) kein Pointer auf Pointer, sondern eine Kennziffern im Sinne einer ID (vergleichbar mit den Dateikennziffern in MS-DOS).
Entscheidend: Diese ID repräsentiert KEINE Speicheradresse, sondern ist ein "abstrakter" Verweis auf eine Resource.
Durch folgende Quelle überprüfbar: "Windows Programmierung - Charles Petzold" 5. Auflage, Seite 54, Abschnitt "Händel mit Handles"
--Starcow (Diskussion) 13:59, 3. Mai 2023 (CEST)
thread_title:  Ein Handle ist kein Pointer auf einen Pointer, sondern eine Kennziffer (ID)