spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Natürlich ist IntelliSense nur ein tolles aber nicht immer verfügbares Feature und es gibt sicherlich Sitationen wo ein Name nicht so eindeutig sein mag. Ich habe aber in all den Jahren in denen ich mich jetzt mit Programmieren beschäftige noch nie eine Situation erlebt in der Ungarische Notation irgendetwas lesbarer gemacht hätte. Eigentlich war imo durchgehend das Gegenteil der Fall. Meiner Erfahrung nach ist, wie gesagt, wenn ein Name nicht eindeutig ist, praktisch immer entweder der Name schlecht oder der Kontext in dem er verwendet wird schlecht gewählt (d.h. das Problem mit dem uneindeutigen Name wäre in einem anderen, besseren Programmdesign nicht vorhanden).

Also mir passiert hier sowas häufig. Leider wurde zwölf Jahre an dem Programm gearbeitet und ich bin erst ein Jahr hier. Viele Stellen im Programmcode sind absolut unverständlich. Das liegt auch daran das das Design teilweise nicht klar ist. Aber wenn ein Programm wächst, lässt sich das schwer vermeiden. Es wäre schön wenn in dem Programm eine klare Linie erkennbar wäre, ist es aber nicht. Und so sieht die Realität in der Regel leider aus. Nun gut, wir sprechen hier auch nicht von einem Hobby Projekt, sondern von einer sehr großen Software die von vielen verschiedenen Leuten geschrieben wurde.

@hanse: Mein Kopf würde platzen, wenn ich mir jedes Interface merken müsste, dass alleine unser Programm hat. Hinzu kommen aber noch viele Klassen und Module von Drittherstellern. Das Programm besteht aus 76 einzelnen Modulen wovon jedes Tausende Zeilen Code hat. Das ganze Projekt kommt gut und gerne auf 500k Zeilen Code. Manchmal muss ich in Bereiche rein wo ich noch nie drinne gewesen bin, und wohl die nächsten Monate auch nicht wieder rein muss. Da würde es helfen mit einem Blick zu erkennen was Sache ist. Ein Problem ist auch, dass viele Variablenname abgekürzt sind. Da ist man dann ganz ratlos.
Das die UN nicht streng definiert ist, ist auch ok. Für ein Projekt/Team sollte sie fest gelegt sein. Aber bei jedem Projekt hast Du andere Anforderungen, da ist es gut wenn man die Definition etwas anpassen kann. Das Einarbeiten in den Style Guide geht recht fix. Viele Firmen haben einen Guide für die ganze Firma. Absolut ok. Imho.

Du hast vorhin explizit von häufig benutzte Interfaces gesprochen und ich habe nur die gemeint, nicht alle. Wenn du in neue Bereiche rein musst, musst du sowieso mal über alles drüber. Ich hab jetzt zwei mal an großen Softwareprojekten gearbeitet (das eine mal sogar: C++, VIM als Editor, keinerlei Coding Convention, also denkbar die "optimalsten" Bedingungen für UN nach deiner Argumentation) und beides mal war die Software gut genug designt das UN komplett unnötig war.
Du sagst die Software ist stellenweise schlecht designt und begründest damit den Einsatz von UN. Das ist als ob du versuchst die Morde eines Serienkillerst zu verhindern in dem du die potentiellen Opfer tötest.

Zitat von »hanse«

Du sagst die Software ist stellenweise schlecht designt und begründest damit den Einsatz von UN. Das ist als ob du versuchst die Morde eines Serienkillerst zu verhindern in dem du die potentiellen Opfer tötest.

Klingt zwar ganz cool, aber irgendwie hinkt der Vergleich, oder?

Hallo

Ein weiterer sehr großer Nachteil an UN ist, dass es sich dabei um eine mehr oder weniger versteckte Dokumentation handelt und die ist in der Regel nie aktuell. Wenn ich also einen Typen ändere, muss ich immer auch dessen Namen änder. Warum sollte ich mir diesen Stress antun? Des Weiteren halte ich es wie dot und glaube, dass UN nur scheinbar zu besser lesbaren Code führt und gerade Konstrukte wie oBlabla für Objekt machen ja die angeblichen Vorteile schon wieder weg. Code ist lesbar oder eben nicht, das hat mit UN erstmal gar nichts zu tun. Er muss gut gegliedert, sehr sorgsam kommentiert und logisch aufgebaut sein. Dann kann man ihn lesen. Die komischen, kryptischen Präfixe stören da eher den Lesefluss.

chrische

Zitat von »dot«

Zitat von »BlueCobold«

Kannst Du mal ein Beispiel machen, bei dem ersichtlich wird, ob es sich um eine lokale Variable, einen Parameter oder um ein Attribut handelt? Das sehe ich nämlich irgendwie nicht, wenn ich z.B. an einen Login-Handler denke, der ein Passwort-Attribut hat, das gleiche aber auch als lokale Variable existieren könnte. Ohne differenzierte Schreibweise sehe ich nicht, wie man da einen Bezeichner so wählen kann, dass der Scope ersichtlich wird. Oder habe ich dich da eventuell falsch verstanden? (über Scope hast Du ja in diesem Quote nicht direkt gesprochen, das war in einem älteren)

Wenn deine Funktionen so lang und unübersichtlich sind dass man den Überblick über die lokalen Objekte verliert dann ist das wiederum ein Indikator für ein Designproblem (die Klasse tut zuviel => schlechter Kontext). Anstatt alles mit ungarischer Notation zu pflastern sollte man dann lieber versuchen den Code so umzustrukturieren dass er übersichtlich wird.

Da kannst du sagen, was du willst, manche Klassen sind eben groß und abstrakt, genau wie manche Methoden eben auch, egal wie weit man sie auf andere Methoden verteilen mag (was damit die Größe der Klasse wiederum beeinflusst). Ich benutze ungarische Notation ebenfalls nicht, markiere aber dennoch Attribute eindeutig, damit ich eben nicht erst in der Methode oder Klasse suchen muss, um herauszufinden, ob es sich um eine lokale Variable/Parameter handelt oder um ein Attribut.
Die Aussage, dass die Klasse oder Methode dann wohl zu groß ist, die weist direkt darauf hin, dass du die Variable also doch nicht aus dem Kontext erkennst, sondern es mit einem zweiten Blick auf die Klasse/Methode nachschaust - egal wie groß oder klein die Klasse/Methode auch sein mag, du brauchst also den zweiten Blick. Das ist aber genau das, was mit z.B. "m_" oder "_" oder wasauchimmer verhindert werden soll. Meine Frage scheint damit geklärt. Anstatt ein schönes Beispiel zu bringen, hast Du Dich nur darüber ausgelassen, was wohl an meinen Sachen falsch wäre.
Sehr schade, ich hatte auf ein konstruktives Beispiel gehofft.

@Architekt: es war ein wenig radikal, aber es stimmt schon. Der Serienmörder ist der schlecht designte Code und statt das eigentliche Problem an zu gehen (ihn fangen/den Code refaktoren) machst du es nur noch schlimmer.

Zitat von »chrische5«

...

Und was spricht jetzt gegen die Notation von Auffälligkeiten? Wie etwa Eigenschaften einer Klasse, Pointer oder sonstigem? In der Regel ist es doch so, dass ich vorher weiß, was ein Pointer, was eine Klasseneigenschaft und was eine statische Variable sein wird.

Hallo

Was alles dagegen spricht, haben ich und andere ja bereits geschrieben, hier aber einen kurze Zusammenfassung, die keinen Anspruch auf Vollständigkeit erhebt:
- Dokumentation, daher Gefahr zu veralten
- kann nicht konsequent gemacht werden -> inkosequente codingstyles
- einfach unnötig, weil der Typ meist klar oder unwichtig ist
- mehr Tipparbeit
- wird selbst von MS nicht mehr benutzt (siehe c#)
- ...

chrische

Ich rede jetzt nicht von "oVar" oder "fVar" oder "iVar" oder "cVar", sondern von "m_Var" und "m_pVar" oder sonstigem. Oder benennst du Eigenschaften einer Klasse etwa ganz normal?

Ungarische notation war zu 80er jahre C-zeiten evtl noch sinnvoll, heutzutage ist es das schlimmste was man einem quellcode antun kann. Finger weg von diesem scheiss.

Zitat von »MCP«

Die Module in denen keine Notation benutzt wurde werden von allen gemieden.

Dann wurden sie von schlechten entwicklern geschrieben. Und wenn euer code ohne ungarische notation nicht lesbar ist, dann will ich den gar nicht sehen. Mir gruselts da schon beim gedanken daran.

Zitat von »MCP«

Ich rede jetzt nicht von "oVar" oder "fVar" oder "iVar" oder "cVar", sondern von "m_Var" und "m_pVar" oder sonstigem. Oder benennst du Eigenschaften einer Klasse etwa ganz normal?

Wie wärs mit "ganz normal"? Gerade der pointer... was ist, wenn du den pointer in eine referenz änderst? Oder ne kopie übergibst? Wenn du eine brauchbare umgebung hast, die dir refactoring bietet, dann sollte die dir auch code-vervollständigung etc bieten. Und wenn sie dir das nicht bietet, dann beschränkt sich dein refactoring gerade mal auf "suchen und ersetzen", womit du eh am arsch bist.

Ich lasse notation höchstens beim "m_" durchgehen (obwohl ich da eher ein this davor bevorzuge) sowie bei Interfaces ein I davor. Ansonsten bringen sprechende namen wesentlich mehr. Und das ist auch verständlicher quellcode.

Vielleicht bin ich aber auch nur arg gebeutelt, weil ich mir quellcode ähnlich diesem scheiss hier antun musste:
und ähnlicher scheiss. Dafür gehören die leute geschlagen.