Sinn und Unsinn der ungarischen Notation

[Gast]

Hallo

Mr Evil schrieb:

"Ungarische Notation"

Sollte man die wirklich noch empfehlen? Ich kann ja verstehen, dass man nicht umsteigen will, aber explizit empfehlen?

chrische

[EXDW]

was waer denn besser ?

[Gast]

Hallo

ohne? Das war ja auch kein Angriff, sondern eine ernst gemeinte Frage. Microsoft selber macht es bei .net ja auch nicht mehr. Zur besseren Übersicht ist es, wenn man mit den MFC arbeiten, wahrscheinlich sinnvoll, aber finde immer wieder, dass es dem Gedanken von OOP entgegensteht.

chrische

[EXDW]

nur fuer solche zwischenvariablen in einer funktion oder member variablen vom typ string, long, double whatever ist es einfacher zu lesen was man hat

class IntCollector { .. };

IntCollector iIntA;
int iIntB;

warum nicht

nur wiel MS es nicht mehr macht hat das nichts zu bedeuten

wenn ich an XAML und .NET denk, da ist keine notation weil einfach kein platz mehr ist #gg
blafasel.DependencyPropertyDeriveredKnartzElementCollector = AlwaysShowTrueValueForDeriveredElements;
(ist natuerlich nur eine verbildlichung)

lieber eine gute notation als lange namen find ich

[Gast]

Hallo

Naja das ist wohl eher eine Glaubensfrage, aber wie man das mit OOP vereinbart hast du nur unzureichend erklärt. Du sagst einfach, dass du es nicht für alle Datentypen anwendest und das ist nicht gerade konsequent. Außerdem sehe ich den Typ, gerade bei lokale, nur kurzlebenden, Variablen in der Regel schon im Quellcode. Ich stehe eher auf aussagekräftige Namen als auf dwValue. Was soll ich mit dieser Information, die keine ist?

chrische

[EXDW]

es ist doch eine information
wenn du zb den eigenen IntCollector als temp benutzt welche du immer wieder ueberschreiben kannst

IntCollector iTmp;
/* ... */
iTmp = 15;
/* ... */
iTmp = 1;

usw usw, und wenn man dann noch eine temporaere vom typ string braucht, warum dann nicht strTmp machen ?
und zudem bekommen members stets ein m_ spendiert, dann erkennt man das durchweg

wobei ich sagen muss das ich dir eigentlich nicht den vorteil der ungarischen notation noch erklaeren muss, gerade wo es in allen groesseren softwareunternehmen absoluter standard ist - auch fuer eigene objekte

class StringElementContainer { ... };
/* - */
StringElementContainer strElemCtn;

wenn ich nu von StringElementContainer erbe, will ich ja spezifizieren, das kann ich ja in einer eigens ausgedachten notation verdeutlichen

class StringIntElementContainer : public SubStringElementContainer { ... };
SubStringElementContainer striElemCtn;

wuesste nicht warum es gegen OOP sein soll, man muss es halt nur anwenden

wobei man an diese stelle sagen wuerde
class ElementContainer { ... };
class StringElementContainer : ElementContainer { ... };
class IntElementContainer : ElementContainer { ... };
usw
aber das spielt keine rolle jetzt, diese namen sind eh viel zu lang #gg

[Gast]

Hallo

Wenn du ableitest, schreibst du sub davor? Da du ja gegen lange Namen bist, frage ich mich, ob man da noch ableiten sollte (subsubsubsubsusbClass) Na ganz toll. Was machst du bei eigenen Datentyp, welches Präfix verwendest du? Das das alle Softwareunternehmen machen, stimmt so ja nun auch nicht (bestes Beispiel ist Microsoft mit .net)

chrische

[EXDW]

hehe, ne ich schreib nicht sub davor, war nur n beispiel, hatte keine lust mir bessere namen auszudenken

> Was machst du bei eigenen Datentyp, welches Präfix verwendest du?
eines was gut identifizierbar ist, und was andere dann auch verstehen
zb wenn man einige eigene objekte hat, blickt man schwerer durch wenn man nicht gleich sieht wie man damit umgehen kann
wenn es ein objekt ist was zahlen representiert, dann schreibt man einfach ein "n" davor - schon weiss jeder das die operatoren fuer < > == = usw fuer dieses objekt funktionieren

und MS ist fuer mich nicht das mass aller dinge, ich bin in einer schon sehr beruemten firma angestellt - und wenn source bekomm und ihn verstehen soll, bin ich dank der guten durchgaengigen notation deutlich schneller und sicherer

ich bins aber nu muessig dir noch den vorteil einer guten notation erklaeren zu muessen
erbe mal code mit ein paar tausend zeilen {auch mehereren hundert pro funktion} ohne notation und erklaer es mir in 30 min

[EXDW]

ich hab eben mal rum gegoogled und bisher nur gefunden das MS sagt ungarische notation sei fuer managed code oder c# nicht mehr zu verwenden, ueber c++ im algemeinen {das ist es hier ja auch} oder MFC wird da nicht gesprochen - zumindest hab ich keine quelle gefunden.
also wie ich schon annahm - fuer cpp ist es noch lange nicht ueberholt

[Gast]

Mr Evil schrieb:

und MS ist fuer mich nicht das mass aller dinge, ich bin in einer schon sehr beruemten firma angestellt - und wenn source bekomm und ihn verstehen soll, bin ich dank der guten durchgaengigen notation deutlich schneller und sicherer

Ich habe nicht geschrieben, dass Microsoft das Mass aller Dinge ist, aber du hast behauptet jede große Softwarefirma würde das machen -> das stimmt anscheinend nicht.

Mr Evil schrieb:

ich bins aber nu muessig dir noch den vorteil einer guten notation erklaeren zu muessen
erbe mal code mit ein paar tausend zeilen {auch mehereren hundert pro funktion} ohne notation und erklaer es mir in 30 min

Du musst mir das auch nicht erklären, aber zu behaupten, das code lesbar ist, weil er die ungarische Notation beachtet, halt ich für Quatsch. da gibt es schon noch ein paar Faktoren mehr. Natürlich ist es wichtig einen Codestyle einzuhalten, aber es dir ungarische Notation sein muss, bezweifle ich.

chrische

[Gast]

Hallo

Mr Evil schrieb:

also wie ich schon annahm - fuer cpp ist es noch lange nicht ueberholt

Ich will wirklich nicht nerven, aber mir fiel noch ein, dass ich auch bei boost oder gar der STL noch nie ein C vor Klassen gesehne habe.

chrische

[EXDW]

und ? was hat das damit zu tun ?
die klasse kann doch heissen wie sie will - in der notation werden nicht die objekte nach etwas benannt sondern die variablen daraus

zb
template<class T> class Sorter { ... };
/* - */
Sorter<int> iSorter;
Sorter<double> dSorter;

oder
class bla
{
std::list<int> m_liVars;
std::vector<int> m_viVars;
};

spaeter irgendwo im code ist das zb viel besser

ps. du nervst nicht - ich fass hier nix als angroff auf {o;

[Gast]

Hallo

Naja in der MFC fangen zum Beispiel alle Klassen C an, aber du hast Recht, dass dies laut dem Artikel bei wikipedia nicht zur Ungarischen Notation gehört. Bleibt trotzdem der Einwand, dass beispielsweise bei boost keine ungarische Notation verwendet wird.

chrische

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