Sinn und Unsinn der ungarischen Notation

[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.

[Gast]

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

[Gast]

Hallo

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

chrische

[Gast]

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.

[Gast]

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.

[dfgfggg]

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.

[otze]

vorallem wirds bei komplexen templates mit der un lächerlich

pointer<Foo<Bar,T>,int,FooBar<Arg1,Arg2,Arg3>,Bar> /*name?*/;

und was ist, wenn sich Typen ändern? wenn aus einem int ein float wird, aus einem char string ein unicode string, oder wenn auf einmal alles auf templates basiert?

[un-fan]

rüdiger schrieb:

Welches Problem willst du mit UN lösen?

Das Universalproblem natürlich : Wie liest (und versteht) man am schnellsten fremde Codezeilen ?

[Gast]

rüdiger schrieb:

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.

Ich verstehe nur nicht, was falsch daran sein soll einer (globalen) Variable z.B. das prä/postfix "angle" oder sowas mitzugeben. Halt einen Qualifier nach einer Konvention.

Edit: Als präfix finde ich das aber auch nicht toll.

[asc]

Ich gebe auch mal meinen Senf zu dem Thema. Meine Meinung nach ist die Ungarische Notation schon aus mehreren Gründen zumindestens in allen modernen OO-Sprachen völlig fehl am Platz. Das liegt zum einen daran das es eine unüberschaubare Anzahl an benutzerdefinierten Typen gibt, und das man an manchen Stellen die Ungarische Notation eh nicht einsetzen kann. Einziges Überbleibsel aus der Zeit ist bei mir noch das I vor einem Interface (und auch das wäre nicht nötig) und in C++ das p für Zeiger, auch wenn ich auch dort inzwischen von Abweiche.

Meine Gründe gegen die Ungarische Notation:

a) Die ungarische Notation erfordert das man noch eine zweite Sprache zusätzlich lernt (Die Kürzel sind zum Teil wirklich nicht lesbar wenn man sich nicht auch noch damit beschäftigt).
b) Moderne IDE's sollten den Typ eh erkennen.
c) Templates/Generics etc. lassen die ungarische Notation eh nicht sinnvoll zu
d) Wenn man den Typ einer Variable ändert, muss man auch das Kürzel anpassen, auch wenn die Bedeutung sich nicht ändert.

Ich bin eh der Meinung lieber aussagekräftige Bezeichnungen zu wählen, da es eh leichter zu lesen ist als irgendwelche kryptische Abkürzungen.

cu André

[Artchi]

Das einzige wo bei mir ein Typ mit in den Namen rein kommt, sind solche Sachen:

class SomeClass
{
    Teilenummer rechtesTeil; // aus der Automotive-Branche
    Teilenummer linkesTeil;

    Button okButton;

};

D.h. vieles kommt bei meinen Benamsungen aus der der normalen Sprache.

[asc]

Artchi schrieb:

...
D.h. vieles kommt bei meinen Benamsungen aus der der normalen Sprache.

Das finde ich auch ganz okay so...

Ein guter Programmierer schreibt Code für Menschen,
ein Schlechter für Computer

...den schließlich muß man Code meist häufiger lesen als schreiben. Und eine natürliche Sprache kann auch ein Anfänger gut verstehen.

cu André

[nicht-UN-freak]

Artchi schrieb:

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

ja, voll komisch. dateien sind doch nur zum lesen da, aber man liest sie nicht aus, sondern schreibt sie raus.

Artchi schrieb:

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

klar, out ist gut. warum nicht gleich nur 'o'? konsequent durchgezogen schont man damit das keyboard und spart platz auf der platte.

asc schrieb:

Ein guter Programmierer schreibt Code für Menschen,
ein Schlechter für Computer

deswegen gibt es auch so viele langsame und fette programme.

[asc]

nicht-UN-freak schrieb:

asc schrieb:

Ein guter Programmierer schreibt Code für Menschen,
ein Schlechter für Computer

deswegen gibt es auch so viele langsame und fette programme.

Wenn du dich damit mal nicht irrst. Ein Programm was zuerst einmal für Menschen geschrieben wird kann leichter optimiert werden als eines das für Computer geschrieben ist.

Zudem
a) Der Code lässt sich besser Warten und Refactorisieren
b) Man benötigt weniger Zeit für Fehler und Einarbeitung, so das mehr Zeit für das eigentliche Bleibt

Eine Optimierung verschlechtert zwar anschließend meist ein wenig die Lesbarkeit, die Optimierung sollte aber eh erst kommen wenn man herausbekommt das es an dem Codeteil liegt.

cu André