Sinn und Unsinn der ungarischen Notation

CStoll

Also ich halte nicht viel von ungarischer Notation (zumindest in der Form, in der sie üblicherweise eingesetzt wird). Wenn, dann sollten diese Kürzel die Aufgabe der Variablen beschreiben und nicht ihren Typ.

(wenn du plötzlich mitten im Programm feststellst, daß eine list<int> doch vorteilhafter als ein vector<int> ist, mußt du alle Vorkommen von "vi" heraussuchen und (teilweise) in "li" umbenennen)

PS: Ich war mal so frei, den Thread aufzuteilen und nach RudP zu verschieben - die Diskussion hatte nicht mehr wirklich mit "double-Überlauf" zu tun.

byto

Welchen Sinn hat Ungarische Notation in Zeiten vernünftiger IDEs? Richtig, keinen.

CStoll

Die Systems Hungarian (und das ist leider die verbreitete Variante) hatte noch nie wirklich Sinn - Apps Hungarian ist durchaus sinnvoll (egal wie gut die IDE wird).

~zum Unterschied empfehle ich einen Blick in den Wikipedia-Artikel~

zwutz

byto schrieb:

Welchen Sinn hat Ungarische Notation in Zeiten vernünftiger IDEs? Richtig, keinen.

och bitte nicht... eine IDE soll niemanden dazu verleiten, nichtssagende Variablennamen wie "zahl1, zahl2, zahl3" usw. zu vergeben.

Die ungarische Notation, richtig eingesetzt, hilft dabei, Variablen sofort ihre Bestimmung anzusehen... ist es eine Zählvariable? Was wird durchgezählt? Welche Typen enthält das Array? usw.

der Wiki-Artikel sollte aufschlussreich genug sein...

byto

Ich sehe nicht, was die Ungarische Notation mir mitteilt, was mir die IDE nicht eh schon offenbart. Niemand hat gesagt, dass man deswegen sinnlose Namen geben soll, aber man braucht sich mit vernünftige IDE nicht mit unaussprechlichen Präfixen die Lesbarkeit versauen.

CStoll

Wenn du sie vernünftig verwendest, teilt sie dir eine ganze Menge mit - zum Beispiel den Unterschied zwischen einem Index und einer temporären Variablen. (korrekt angewendet geht es NICHT darum, den Variablentyp nochmal in den Namen reinzucodieren, sondern die Aufgabe der Variable zusammenzufassen)

rüdiger

Ungarische Notation macht keinen Sinn, da der Typ einer Variable in der Regel unwichtig ist. Das Konzept/Verhalten welches hinter einer Variable/Objekt steht ist das wichtige. Das konkrete Typinformationen da einfach nerven sieht man ja an dem Nutzen der ganzen generischen Programmierung, wo man eben bewusst die später Typbindung einführt.

Ganz zu schweigen davon, dass der Code effektiv unleserlicher wird. Die Variablennamen werden unleserlicher und man kann sie sich schwerer merken. Die Notation ist ohnehin nicht einheitlich, deshalb muss man sich für jedes Projekt an neue Richtlinien gewöhnen etc.

CStoll

rüdiger schrieb:

Ungarische Notation macht keinen Sinn, da der Typ einer Variable in der Regel unwichtig ist. Das Konzept/Verhalten welches hinter einer Variable/Objekt steht ist das wichtige.

Auch auf die Gefahr hin, mich zu wiederholen - im ursprünglichen UN-Ansatz ("Apps Hungarian") kennzeichneten die Kürzel auch das Konzept/Verhalten. Nur waren die Microsoft'ler so clever, diesen Punkt misszuverstehen (und heutzutage denkt jeder erstmal an das, was sie aus UN gemacht haben ).

rüdiger

Das Konzept/Verhalten sollte der Name auch ohne kryptische Kürzel erläutern. Aber wenn man kurze Funktionen schreibt und keine globalen Variablen benutzt, dann ist die ganze Frage ohnehin obsolet.

Artchi

Also ich habe mal gelesen, das der Erfinder dieser Notation nur ungarisch konnte, und sich deshalb mit der Notation so mit seinen englisch sprachigen MS-Kollegen verständigen konnte.

Alleine diese wahnwitzige Annekdote macht mehr als deutlich, wie unsinnig diese UN ist. Vorallem in C++ noch unsinniger, da ich doch heute schon allein wegen typedef einen Typen jeder Zeit im Background auf einen anderen Typen umstellen kann und die Notation somit völlig an Wahrheit verliert.

Denn was ist die UN? Eine verkappte Dokumentation des Codes im Code (und nicht in Kommentaren). Und was tut Dokumentation für gewöhnlich? Genau, sie lügt! Sie Lügt wenn sie in KOmmentar-Blöcken steht, sie lügt wenn sie in einem PDF steht und sie lügt auch in einem Code.

tfa

Ich finde es unverständlich, sich heute noch für die UN (in objektorientiere Programmiersprachen) einzusetzen oder sie zu verwenden. Eine vernünftige IDE sagt viel mehr über die Typen einer Variablen als irgendeine Notation (und das viel sicherer).

Artchi schrieb:

Denn was ist die UN? Eine verkappte Dokumentation des Codes im Code (und nicht in Kommentaren). Und was tut Dokumentation für gewöhnlich? Genau, sie lügt! Sie Lügt wenn sie in KOmmentar-Blöcken steht, sie lügt wenn sie in einem PDF steht und sie lügt auch in einem Code.

Richtig! Und es ändert auch nichts daran, welche "Art" der UN man verwendet. "Apps" und "Systems" unterscheiden sich in dieser Weise überhaupt nicht von einander. Ich meine, diese Unterscheidung ist eh nur ein nachträgliches Rechtfertigen der UN-Verfechter angesichts der Nachteile.
Es gibt nur eine Sorte UN, die nutzlose.

Möglicherweise ist das auch ein Generationenkonflikt. Nach meiner Beobachtung verteufeln die meisten UN-Verfechter automatische Garbage-Collection, wollen selber festlegen, ob ihre Objekte auf dem Stack oder dem Heap erzeugt werden, finden Präprozessoren nützlich und rücken ihre Quelltexte mit Tabs statt Spaces ein.

Welche Alternative wird denn von den Kritikern vorgeschlagen? Welche wird benutzt?

Hallo

Ich versuche sinnvolle, also beschreibende Namen zu verwenden: fileToReadOut,...

chrische

Gut, aber das ist ja nun auch keine Konvention.

Artchi

Ich benutze gar keine Notation. Sagen wir mal Member-Variablen. Ich schreibe nicht sowas:

class SomeClass
{
     wstring mws_name;
};

Nein, ich brauche kein m für Member und kein ws für wstring.

class SomeClass
{
     wstring name;
};

Wofür steht die Variable? Genau, für einen Namen. Der Typ kann sich aber jeder Zeit in ein u32string-Typ oder sogar in einen Typ PersonName ändern:

class SomeClass
{
     PersonName name;
};

Es ist IMMER im Kontext gesehen ein Name. Deshalb ändere ich den namen nicht auf mpn_name um.

Was interessiert mich der genaue Typ? Für die Lösung der gestellten Aufgabe muß ich mit einem Namen rumhantieren. Der _genaue_ Typ ist zweitrangig (nicht unwichtig!). Aber ich kann aus dem "name" semantisch wissen, das es eine Art Wort oder Zeichenkette sein soll. "name" kann schlecht eine Geschwindigkeit sein... z.B. vom Typ "int" oder vom Typ "Tempo". Dann hätte ich die Variable eher anders benennen sollen.

Jester

chrische5 schrieb:

Ich versuche sinnvolle, also beschreibende Namen zu verwenden: fileToReadOut,...

und dann natürlich auch fileToReadIn, fileToWriteOut und fileToWriteIn.

Hallo

Was ich sagen wollte: Ich versuche Namen zu verwenden, die beschreiben, wofür die Variable da ist. Das ist schon alles. Da ich in letzter Zeit immer mal mit c# rumhantiere, verwende ich zur Namensgebung, die dort üblichen Konventionen.

chrische

Artchi

Naja, Jester wollte eher sagen, das es komisch ist ein Datei rein zu schreiben. Eine Datei schreibt man eher raus.

Wobei ich trotzdem die Namensgebung zu lang finde, da zu viele Wörter in dem Variablenname. out oder outfile würde auch reichen.

ungarische notation ist totaler schrott. punkt. wer was anderes behauptet, hat kein plan!

rüdiger

Tim schrieb:

Welche Alternative wird denn von den Kritikern vorgeschlagen? Welche wird benutzt?

Welches Problem willst du mit UN lösen? Dann sage ich dir meine Alternative dazu.