Ungarische Notation veraltet



  • 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