Ungarische Notation veraltet



  • 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



  • 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.69)
    [...]
    69)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.



  • Kenrik schrieb:

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

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


  • Administrator

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



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



  • Kenrik schrieb:

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

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



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



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



  • 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?



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



  • ... 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 );



  • ... 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++.


Anmelden zum Antworten