Ungarische Notation veraltet

groovemaster

Dravere schrieb:

1. Lesbarkeit. Genau das, wo so viele sagen, dass es nicht gefördert wird. Also ich weiss nicht aber ich kann einen Code der mit der ungarischen Notation versehen ist, deutlich schneller lesen und verstehen, als einer ohne. Wenn viele Variablen am Anfang einer grösseren Funktion deklariert werden oder in eine Klasse usw. dann kann ich mir nicht auswendig merken von welchem Typ jede Variable ist. Und ich will nicht immer mit der Maus über die Variable gehen, während dem Lesen um zu schauen von welchem Typ die ist.

Stimmt, Tooltips sind in ihrer Anwendung ja auch so schwer und kompliziert.
Zudem zieht das Argument in C++ sowieso nicht. Erstmal verwendet man unter C++ in place Definition. Also dort, wo eine Variable verwendet wird, wird sie auch definiert. Und zweitens, C++ ist objektorientiert, und nicht typorientiert. Was interessiert mich zB bei

cout << x;

welchen Typ x hat? Ist doch absolut irrelevant. Mich interessiert nur, dass x ausgegeben wird. Nicht mehr und nicht weniger. Dass Typen natürlich schon ihre Bedeutung haben, sollte auch klar sein. Man darf sie aber nicht über alles stellen.

Dravere schrieb:

2. Kürzere Variablen.
int nNamen;
Ist für mich klar, eine Anzahl Namen
int NamenCount;
Muss es mindestens ohne Notation heissen, denn unter Namen könnte man auch alles andere verstehen.

Was bei nNamen aber genauso ist. Für dich ist es die Anzahl, für jemand anderen die Gesamtlänge. Damit kommen wir auf keinen grünen Zweig. NamenCount ist da schon relativ eindeutig. Und wie war das mit pZy und den faulen UN Verfechtern? Nur weil ein Name kürzer ist, heisst das noch lange nicht, dass er damit lesbarer und aussagekräftiger ist.

Dravere schrieb:

3. Variablennamen doppelt verwenden und trotzdem Klarheit. Zudem werden sie auch wie in 2. kürzer.
int nFirstAssist;
Nummer des FirstAssist Spielers.
CString strFirstAssist;
Name des FirstAssist Spielers.

Irgendwie kann ich dich nicht ernst nehmen. Wenn das so klar wäre, wieso schreibst du dann noch eine Erklärung dazu? Bei einer sinnvollen Benennung würde das jedenfalls FirstAssistNumber und FirstAssistName heissen. _Das_ ist klar.

Dravere schrieb:

4. Ich kann auch Quellcode als Text verschicken und darin ist dann auch noch klar, als was die Namen gemeint sind. Gerade für eine Dokumentation zu einem Quellcode, denke ich ist dies sehr angenehm.

Genauso kryptisch wie UN, ist dieser Satz. Wahrscheinlkich weisst nur du, was damit gemeint ist, bzw. welche Vorteile dies zum Ausdruck bringen soll.

Dravere schrieb:

5. Und ich wage nun sogar was ganz gemeines zu behaupten, damit man mich auch brav stark auseinander nimmt, ihr seid doch nur zu faul um die ungarische Notation zu lernen.

Wieso sollte man abgestandenes Fleisch konservieren? Es bleibt so oder so ungeniessbar.

Dravere schrieb:

Denn die Beispiele, welche hier teilweise aufgelistet wurden, waren manchmal sowas von schön. Klassen ohne Unterscheidung von privat, protected und public und so vereinfacht, wie wohl nie irgend eine Klasse aussehen wird. Klar sieht sie dann gleich aus wie eine Struktur und man fragt sich dann wieso sollte man nun ein C für Klassen verwenden und z.b. ein S für Strukturen. Die Sache ist aber die, dass halt Klassen oft komplexer sind und z.b. mehr Funktionen und solches Zeug anbieten, während eine Struktur oft nur eine Auflistung von verschiedenen Variablen ist ganz ohne Funktionen. Zudem ist es dann auch angenehmer und schneller zum unterscheiden zwischen Objekttyp und Variable.

Was hat das eine denn mit dem anderen zu tun? Einer Namenskonvention ist semantische Funktionalität doch vollkommen egal. Zudem unterscheidet man in C++ nicht zwischen Klassen und Strukturen, sondern, wenn überhaupt, zwischen PODs und Non-PODs.

Dravere schrieb:

Deshalb sag ich, dass ich sie nicht zu 100% kann. Aber irgendwann mal muss ich mir endlich eine einzige angewöhnen. Vor allem, wenn es bei mir mal wirklich professionell werden sollte

Siehst du, deshalb ist solch eine Art von Kryptografie nutzlos. Anstatt sich mit solchen Problemen rumzuschlagen, könntest du dich auch besser auf die wirklich wichtigen Dinge bei der Entwicklung konzentrieren.

Dravere schrieb:

ErgebnislisteGeladen könnte auch ein Integer sein, denn if(5) if(10) usw. geht auch und wird auch als true angesehen.

Deshalb bin ich auch kein Freund von impliziten boolschen Umwandlungen. Benutze sowas selbst eigentlich nur bei Zeigern. Ansonsten, wenn ich ein int Argument habe, dann schreibe ich auch

if (x != 0)

und nicht

if (x)

Dravere schrieb:

Das b stört den Lesefluss auf keinen fall, nein es sagt mir sofort, ach das ist ein bool wert, also nur 1 oder 0. Das kann somit nur darum gehen ob die Ergebnisliste bereits geladen wurde oder nicht. Man kommt gar nicht auf die Idee, dass es etwas anderes sein könnte, denn es wird simpel einfach ausgeschlossen.

Oder man könnte die Variable auch IstErgebnislisteGeladen nennen, dann gibts auch keine Missverständnisse.

pZy schrieb:

Hab früher (Anfangszeiten) auch HN benutzt, aber einfach aus dem Grund heraus, weil ich zu FAUL war und es mir zu schwer viel mir RICHTIGE Namen für meine Valiablen auszudenken.

Ich denke, das ist das eigentliche Hauptproblem von UN Befürwortern. Sich lieber hinter kryptischen Namenskodierungen zu verstecken, anstatt sinnvolle und sprechende Namen zu verwenden, kann auf Dauer keine Lösung sein.

Kenrik schrieb:

Wenn jemand meine pdf gelesen hätte(jaja ich weiß, Informatiker und rtfm...)
müsste klar sein, das die Hauptaussage der (orginalen) Ungarischen Notation NICHT bei den Datenypen liegt

Die meisten, die hier von UN sprechen, meinen damit aber Microsoft UN. Und darum geht es hier im Grunde auch.

Kenrik schrieb:

Ich würde unter Anwendung der Ungarischen Notation die Variable eher so schreiben: bool fbErgebnislisteGeladen (f=flag, b=byte da bool=1byte).

War byte nicht by? Und dass bool 1 Byte gross ist, existiert auch nur in deinem Universum. Zumindest wenn man es aus C++ Sicht betrachtet.

Kenrik schrieb:

Können wir uns nicht einfach darauf einigen dass die ungarische Notation einfach nur scheisse und überflüssig ist?

Ich finde das niveaulose Rumgeflame in diesem Thread ehrlich gesagt als störend...

Die Worte waren zwar harsch gewählt, kommen der Realität aber sehr nah. Auch wenn du das als Geflame bezeichnet, anno 2006 solltest du den Tatsachen einfach ins Auge schauen. Namenskonventionen sind ok, speziell wenn mehrere Leute an einem Projekt arbeiten. UN ist jedoch unnützer Ballast.

net 0

groovemaster schrieb:

NamenCount ist da schon relativ eindeutig.

naja, so'n mixmax aus deutsch und english ist aber auch ziemlich doof...

groovemaster

Ja ok, das könnte man noch bemängeln. Da sollte man schon _eine_ Sprache verwenden.

War byte nicht by?

In Apps Hungarian ist es b.

Und dass bool 1 Byte gross ist, existiert auch nur in deinem Universum. Zumindest wenn man es aus C++ Sicht betrachtet.

Da muss ich dir widersprechen und sizeof(bool) stimmt mir zu .

UN ist jedoch unnützer Ballast.

Zu Systems Hungarian (das nicht mit der Ungarischen Notation gleichgesetzt werden sollte) stimme ich dir voll und ganz zu. Die einzige gute Idee waren die Sichtbarkeitspräfixe (und das s_ was ich da mal dazu zähle).
Mir ist klar, dass die meisten von euch Systems Hungarian als die Ungarische Notation sehen. Wahrscheinlich vor allem deswegen, weil Microsoft SystemsH in so ziemlich allen Bereichen verwendet(z.B. WinAPI) bzw. verwendet hat.

Hier übrigens noch ein interessantes Paper über Bennenungskonvention und die Ungarische Notation.

http://www.joelonsoftware.com/articles/Wrong.html

groovemaster

Kenrik schrieb:

Da muss ich dir widersprechen und sizeof(bool) stimmt mir zu .

Wenn du mir schon widersprichst, dann solltest du wissen, wovon du redest.

sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result of sizeof applied to any other fundamental type (3.9.1) is implementation-defined. [Note: in particular, sizeof(bool) and sizeof(wchar_t) are implementation-defined.⁶⁹⁾
[...]
⁶⁹⁾sizeof(bool) is not required to be 1.

"bool=1byte" ist eine rein implementationsspezifische Beobachtung, also nichts Wichtiges.

Mein Fehler. Ich hatte bis jetzt nie den Fall das bool != 1Byte. Vielleicht auch deswegen weil man eher selten den sizeof(bool) braucht.

net 0

Kenrik schrieb:

-1 = (-1)^1 = (-1)^(2 * 0,5) = ((-1)²⁾0,5 = 1^0,5 = 1
=> 1=-1

was hast du für'ne komische rechnung in der signatur?

Dravere

@groovemaster

Ich will jetzt nicht auf alles antworten, da ich eigentlich immer noch von dem was ich gesagt habe überzeugt bin, auch nach deiner Argumentation. Aber auf etwas möchte ich noch eine Antwort geben.

groovemaster schrieb:

Was interessiert mich zB bei
cout << x;
welchen Typ x hat? Ist doch absolut irrelevant. Mich interessiert nur, dass x ausgegeben wird. Nicht mehr und nicht weniger. Dass Typen natürlich schon ihre Bedeutung haben, sollte auch klar sein. Man darf sie aber nicht über alles stellen.

Weisst du, es gibt halt Leute auf dieser Welt, die sich dafür interessieren, was z.b. da Ausgegeben wird und nicht nur damit zufrieden sind, wenn es heisst: "Es Funktioniert!". Man möchte halt verstehen wieso und x kann schlichtweg alles sein. Also insofern ist dies die absolut schlechteste Lösung von allen, ausser du machst natürlich was wie:

for(int x = 0; x < 200; ++x)
{ std::cout << x; }

Aber ich glaube nicht, dass du es so gemeint hast. Ich meine ich habe nichts gegen die andere Methode, einfach nur mit den Namen, aber mir gefällt einfach noch die ungarische Notation dazu. Ich find es einfach noch ein wenig besser.

Zudem muss ich noch was sagen. Einen Punkt (der total überflüssig und unwichtig ist) hat es noch. Es sieht professioneller aus :p ...

Zudem ist es nicht abgestandenes Fleisch. So wie ihr argumentiert, oder einige argumentieren, ist es seit C++ da ist unnötig. Daher war es von eurer Sicht aus, einfach gar nie nötig.
Da fragt man sich dann manchmal schon wieso es eingeführt wurde. :p

Grüssli

was hast du für'ne komische rechnung in der signatur?

Ist ein kleines mathematisches Rätsel frei nach dem Motto: Such den Fehler.
(Ausser du lässt dich davon überzeugen, dass -1 gleich 1 ist)
Bin kleiner Mathe-Fan

Um nicht ganz Abseits von btt zu sein:
Die Geschichte wie es zu Systems Hungarian kam recht interessant, da das ein schönes Beispiel dafür ist, dass in großen Softwarehäusern (hier Microsoft) oft die eine Hand nicht weiß was die andere tut.

Apps Hungarian was extremely valuable, especially in the days of C programming where the compiler didn’t provide a very useful type system.
But then something kind of wrong happened.
The dark side took over Hungarian Notation.
Nobody seems to know why or how, but it appears that the documentation writers on the Windows team inadvertently invented what came to be known as Systems Hungarian.
Somebody, somewhere, read Simonyi’s paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn’t help. The damage was done.
Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.
Systems Hungarian had far less useful prefixes like “l” for long and “ul” for “unsigned long” and “dw” for double word, which is, actually, uh, an unsigned long. In Systems Hungarian, the only thing that the prefix told you was the actual data type of the variable.
This was a subtle but complete misunderstanding of Simonyi’s intention and practice, and it just goes to show you that if you write convoluted, dense academic prose nobody will understand it and your ideas will be misinterpreted and then the misinterpreted ideas will be ridiculed even when they weren’t your ideas. So in Systems Hungarian you got a lot of dwFoo meaning “double word foo,” and doggone it, the fact that a variable is a double word tells you darn near nothing useful at all. So it’s no wonder people rebelled against Systems Hungarian.

net 0

Kenrik schrieb:

Ist ein kleines mathematisches Rätsel frei nach dem Motto: Such den Fehler.

das ist doch viel zu einfach (nur falsch geklammert)

Nein. Die Klammerung stimmt. Das Problem liegt wo anders.
Aber das sollte nicht hier diskutiert werden. Wenn dann mach einen Thread in Mathematik auf. Könnte aber sein, dass es das schonmal gab, da das Rätsel doch schon bissl älter ist.

net 0

Kenrik schrieb:

Nein. Die Klammerung stimmt. Das Problem liegt wo anders.

naja, sagen wir mal: 'bewusst' falsch geklammert damit das minus verschwindet

Khadgar

[ automatisch ] schrieb:

Die ungarische Notation ist doch vollkommen überflüssig. Mit neuen IDEs kann man sowieso den Variablentyp einfach feststellen. Außerdem ist sie total kryptisch und man bringt schnell was durcheinander und muss nur unnötig viel tippen. Und wenn der Code sauber strukturiert ist kann man den Typ auch ohne viel scrollen herausfinden.

§$%#-%%( Trolle

groovemaster

Dravere schrieb:

Weisst du, es gibt halt Leute auf dieser Welt, die sich dafür interessieren, was z.b. da Ausgegeben wird

Das ist richtig, ist aber für die Implementation doch vollkommen belanglos. Sofern ein gültiger op << existiert, läuft alles wie Butter.

Dravere schrieb:

Zudem muss ich noch was sagen. Einen Punkt (der total überflüssig und unwichtig ist) hat es noch. Es sieht professioneller aus :p ...

Klar, wenn für dich lpszText oder cchLength professioneller aussieht.

Dravere schrieb:

Zudem ist es nicht abgestandenes Fleisch. So wie ihr argumentiert, oder einige argumentieren, ist es seit C++ da ist unnötig. Daher war es von eurer Sicht aus, einfach gar nie nötig.

Richtig, es war noch nie notwendig. Und seit C++ kapieren es die Leute auch. Naja, zumindest 'ne ganze Menge. Und moderne IDEs liefern dazu auch ihren Beitrag.
Ich frage mich, ob du überhaupt schon mal ohne UN etwas gemacht hast. Ich habe nämlich das Gefühl, dass du überhaupt nicht weisst, womit du argumentierst. Ich habe früher selbst mit UN gearbeitet, ganz einfach, weil ich es so aus diversen Büchern und Tutorials kannte. Irgendwann habe ich das dann einfach weggelassen, und das war eine richtige Erleichterung. Negative Auswirkungen habe ich dennoch nicht feststellen können. Und da bin ich nicht der Einzige mit diesen Erfahrungen. Irgendwas muss also dran sein, was die ganzen "Anti-UN Trolle" so von sich geben.

Ich will dich nicht von deinem Glauben abbringen. Wenn du weiterhin überzeugt bist, UN benutzen zu müssen, dann mach das. Aber glaube mir, deine Produktivität wird das mit Sicherheit nicht fördern. Eher mit dem Gegenteil ist zu rechnen.

DEvent

Edit: hab das mit den Sichtbarkeiten falsch verstanden *gelöscht*

Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.

Das ist doch endlich mal eine sinnvolle Verwendung von Präfixen.
Wen interessiert es ob die Defferenz zwischen zwei Werten eine Fließkommazahl oder eine nat. Zahl ist. Wenn ich der Defferenz eine Fließkommazahl zuweisen kann, dann ist es ok. Wenn nicht dann liefert mir der Compiler einen Fehler. Dafür ist er da.

Hier übrigens noch ein interessantes Paper über Bennenungskonvention und die Ungarische Notation.

http://www.joelonsoftware.com/articles/Wrong.html

Hab mal überflogen den Text, und würd gern paar Dinge kritisieren.
Die Beispiele mit C und XSS, vor allem C: wenn man die Sprache nicht kann sollte man sie lassen. Da nützen auch keine Krücken wie UN.

Man braucht sich doch nur an paar Dinge zu halten:
1. Man muss wissen was man tut.
Wenn man mit Zeigern arbeitet, darf man nicht vergessen sie freizugeben, usw.
2. Man muss das Interface so sicher und einfach wie nur möglich machen.
Also keine Zeiger zurückliefern, Methoden wo es nur geht als const markieren, lieber Referenzen statt Zeiger erwarten, für Nachrichten eigene Klassen/Interfaces implementieren (also nicht mit void* arbeiten).
3. Namen eindeutig und aussagekräftig bennen, so das man die Sprache wie eine nat. Sprache lesen kann.
z.b. getName(); getAdressenAnzahl(); istArbeitFerdig();
Wozu braucht man da noch irgendwelche Präfixe, die Leute die die Benutzen, sind einfach zu faul um die 3 einfache Dinge zu beachten.

Bestes Beispiel ist die Java API, in der vollständig auf Prä/Postfixe verzichtet wurde.

Wen interessiert es ob die Defferenz zwischen zwei Werten eine Fließkommazahl oder eine nat. Zahl ist. Wenn ich der Defferenz eine Fließkommazahl zuweisen kann, dann ist es ok.

Das sagt sich halt leicht, aber gerade wenn man mit eher typunsicheren Sprachen arbeitet wie C, kann sowas auch nach hinten los gehen. Einfachstes Beispiel wär die Funktion printf() mit dem Formatstring, denn dieser wird auch nicht vom Compiler überprüft, allerdings kann es Folgen mit sich ziehen, wenn dieser falsch angegeben wurde.

printf("%s", foo);

Kannst du mir jetzt sagen, ob dieser Aufruf einen Fehler verursachen wird oder nicht?

rüdiger

... schrieb:

Wen interessiert es ob die Defferenz zwischen zwei Werten eine Fließkommazahl oder eine nat. Zahl ist. Wenn ich der Defferenz eine Fließkommazahl zuweisen kann, dann ist es ok.

Das sagt sich halt leicht, aber gerade wenn man mit eher typunsicheren Sprachen arbeitet wie C, kann sowas auch nach hinten los gehen. Einfachstes Beispiel wär die Funktion printf() mit dem Formatstring, denn dieser wird auch nicht vom Compiler überprüft, allerdings kann es Folgen mit sich ziehen, wenn dieser falsch angegeben wurde.
printf("%s", foo);
Kannst du mir jetzt sagen, ob dieser Aufruf einen Fehler verursachen wird oder nicht?

so kann man das natürlich nicht sagen. Aber mit printf("%s", s_foo); wüßte ich es auch nicht. Steht s für short, string, struct oder was auch immer? Wäre pc_foo leserlicher? Sicher nicht.

Ich würde eher auf printf verzichten. Das ist eh keine gute Funktion, so wie der größte Teil der C Standard Library.

groovemaster

... schrieb:

Das sagt sich halt leicht, aber gerade wenn man mit eher typunsicheren Sprachen arbeitet wie C, kann sowas auch nach hinten los gehen. Einfachstes Beispiel wär die Funktion printf() mit dem Formatstring, denn dieser wird auch nicht vom Compiler überprüft, allerdings kann es Folgen mit sich ziehen, wenn dieser falsch angegeben wurde.

Ja, die ganzen print und scan Funktionen gehören sicherlich nicht gerade zur Sternstunde von C. Es gibt allerdings Compiler, die selbst dort Typprüfungen durchführen, zB GCC. Aber auch mit UN heisst das noch lange nicht, dass du auf der sicheren Seite bist. Ein Compiler macht nunmal keine Syntaxprüfung bzgl. UN. Letztendlich reduziert sich die Fehleranfälligkeit dabei auf den Faktor Mensch. Nicht besonders beruhigend wenn du mich fragst.

printf( "%s", strFoo );

Daniel E.

... schrieb:

Das sagt sich halt leicht, aber gerade wenn man mit eher typunsicheren Sprachen arbeitet wie C,

Huch? C hat bis auf eine kleine Änderung das gleiche Typensystem wie C++.