spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Wümpftlbrümpftl«

Also ich persönlich (!) finde "m_" usw. allein schon praktisch, weil dann lokale Variablen in bestimmten Fällen schonmal den selben Namen haben können (vorallem bei Parametern im Konstruktor immer sehr anschaulich dann).


So oder so lassen sich aus der Diskussion doch 2 Dinge über ungarische Notation feststellen:
- Sie ist vollkommen geschmacksabhängig und der Einsatz pure Gewohnheit: Manche lieben es, einige hassen es, wieder andere mögens nich können aber darüber hinweg sehen
- Ungarische Notation muss (wenn sie den schon da ist) konsequent und logisch sein
Ansonsten gilt das was "Helmut" doch immer in seiner Signatur hatte (hat?): „Sei stets geduldig gegenüber Leuten, die nicht mit dir übereinstimmen. Sie haben ein Recht auf ihren Standpunkt - trotz ihrer lächerlichen Meinung.“

Wer widerspricht mir?

Also ich glaube der Beweis für geschmacksabhängig wurde hier im Thread erbracht. Eine Diskussion mit 90 Beiträgen über solch eine unwichtige Nebensächlichkeit

Jaaah was man in der Zeit alles an Code hätte schreiben können.. gar nicht auszumalen :lol:

Zitat von »BlueCobold«

Aber mal angenommen die Klasse von dot hat noch 3 weitere solcher Methoden. Gerade bei einer solchen Klasse wie "AnimatedModel" kommt sehr schnell sehr viel Code zusammen, ich sehe nicht, wie man den sinnvoll umgehen könnte. Aber mal zurück... angenommen er hat noch 3 weitere solch großer Methoden und fängt nun an diese sinnvoller aufzusplitten, dann hat er aus 4 Spaghetti-Methoden 16 Methoden gemacht, die alle gut lesbar und kurz sind. Aber was hilft ihm das, denn nun hat 12 Overhead-Methoden, die eigentlich keinen echten Klassen-Zweck erfüllen, sondern nur irgendwelchen privaten Code ausführen? Ist das nicht künstliches Aufblähen der Klasse? Wie verhindert ihr denn sowas, das ist mir irgendwie unklar.

Für mich klingt das dann eher danach, als würdest du prozedurale programme in klassen verpacken. Klassen allein machen aber objektorientierung noch nicht aus. Viel des genutzten codes liegt doch oftmals sowieso in anderen klassen. Eine "gameobjekt" klasse hat zB nen mesh, aber das ist im allgemeinen ja eine eigene klasse. Ein mesh hat ne textur, im allgemeinen auch eine eigene klasse. Ein gameobjekt hat evtl einen vordefinierten pfad auf dem es sich bewegt. Auch wieder ne eigene klasse. Renderstates, wieder ne klasse. Meistens hast du dann nicht 12 "overhead"-methoden, sondern eher methoden sinnvoll in klassen verteilt dort wo sie hingehören.
Grosse methoden die viel magic code ausführen (welcher dann auch noch dutzende private member ändert) ist schwer zu testen und schwer zu warten. Lieber kleine methoden, die genau eine klar abgegrenzte aufgabe haben. Am allerbesten ist es natürlich, wenn diese methoden dann noch const sind. Die lassen sich dann leicht durch einen unit-test jagen.

Zitat von »KeksX«

Mir persönlich läufts auch eiskalt über den Rücken, wenn ich Code wie bei MasterK vor Augen habe.

Der code ist natürlich von den funktionsnamen her nicht brauchbar, es ging dabei aber nur um die struktur von code. Könntest du mir erklären, was dir da "eiskalt über den rücken läuft"? Wenn dir gut strukturierter code nicht gefällt, bin ich froh dich nicht als kollegen zu haben. Muss mich eh schon viel zu häufig mit kilometerlangen methoden und kryptografischen benamungen rumschlagen

Zitat von »KeksX«

Aber wie gesagt, ich sehe nicht ein wieso "m_p" oder "m_s" oder "_s"(wobei _s ja fast auch unnötig ist und imho auch weggelassen werden kann) oder sonstwas schlecht sein sollte.

Wie gesagt, gegen das m_ an sich hab ich ja nix. Aber p_? Ist dir in den sinn gekommen, dass man in OOP-sprachen ziemlich häufig auch smartpointer einsetzt? Unterscheidest du die auch anhand von prefixen? Wenn nicht, warum nicht? Für mich klingt das so, als wenn du das "p_" nur nutzt, um zu entscheiden, ob du "->" oder "." schreibst...

Zitat von »KeksX«

Also sorry, ich kann die Argumentation gegen "teilweise Ungarische Notation" nicht verstehen, erstrecht nicht den Vorwurf, es breche die Objektorientierung.

Es "bricht" nicht die OOP, aber ungarische notation reicht nicht, um in OOP sinnvoll angewendet zu werden. Das array beispiel habe ich ja schon gebracht, jetzt grad noch die pointer. Der typ einer variable hat im namen einfach nix zu suchen. Denn bei OOP lande ich dann in der situation: "oh, also bei dem pointer, da pack ich nen 'p_' dran, bei dem smartpointer aber nicht. Und bei array, da pack ich nen 'a_' ran, beim vector aber nicht". Womit der code wieder unleserlich und inkonsequent wird.

Zitat von »MasterK«

Es "bricht" nicht die OOP, aber ungarische notation reicht nicht, um in OOP sinnvoll angewendet zu werden.

Das hat auch niemand behauptet.

Zitat von »MasterK«

"oh, also bei dem pointer, da pack ich nen 'p_' dran, bei dem smartpointer aber nicht. Und bei array, da pack ich nen 'a_' ran, beim vector aber nicht". Womit der code wieder unleserlich und inkonsequent wird.

Deine Argumentation ist sehr unlogisch: Ein p (nicht "p_"!) vor einem Pointer bringt viel, z.B. wenn du diesen Fall hast, du hast eine Klasse Model, die eine Variable vom Typ Texture (kein Zeiger) beinhaltet, es gibt eine Funktion SetTexture(), die einen Pointer auf eine Texture erwartet und den Wert des Pointers der Membervariable zuweist. Mit p hast du gleich 2 Vorteile:
1. Der Textur-Parameter der Funktion kann gleich heißen (also pTexture und die Membervariable m_Texture)
2. Jemand, der die Klassendefinition nicht kennt weißt der Membervariable nicht die Adresse des Zeigers oder so zu, sondern weiß durch die Präfixe, dass es sich bei dem Parameter um einen Zeiger handelt.

Außerdem, wie sind deine Vektoren definiert? Ein Array ist bei mir etwas, wie int aiValues[100] und ein Vector eine Struktur, die 3 Variablen (x, y und z) enthält.

Zitat von »BurningWave«

Deine Argumentation ist sehr unlogisch: Ein p (nicht "p_"!) vor einem Pointer bringt viel, z.B. wenn du diesen Fall hast, du hast eine Klasse Model, die eine Variable vom Typ Texture (kein Zeiger) beinhaltet, es gibt eine Funktion SetTexture(), die einen Pointer auf eine Texture erwartet und den Wert des Pointers der Membervariable zuweist. Mit p hast du gleich 2 Vorteile:
1. Der Textur-Parameter der Funktion kann gleich heißen (also pTexture und die Membervariable m_Texture)

Also DAS ist doch mal ein vorteil. Wie wärs, wenn wir den parameter einfach "texture" nennen?

Zitat von »BurningWave«

2. Jemand, der die Klassendefinition nicht kennt weißt der Membervariable nicht die Adresse des Zeigers oder so zu, sondern weiß durch die Präfixe, dass es sich bei dem Parameter um einen Zeiger handelt.

Und genau hier sehe ich schon den design-fehler: wenn der _wert_ des pointers zugewiesen wird, warum zum geier übergibst du dann einen pointer und keine referenz? Hier einen pointer zu verwenden halte ich für fehleranfällig. Wenn ich einer funktion "SetTexture" (man beachte das "set") einen pointer zuweise, dann erwarte ich evtl., dass die klasse den pointer hält und ihn evtl auch aufräumt. Da das in deinem beispiel aber gerade nicht passiert, sehe ich für die verwendung von pointern keinen nutzen, nur fehlerquellen. Also nimmt man referenzen, womit sich das leidige "p"-problem eh in wohlgefallen auflöst.

Zitat von »BurningWave«

Außerdem, wie sind deine Vektoren definiert? Ein Array ist bei mir etwas, wie int aiValues[100] und ein Vector eine Struktur, die 3 Variablen (x, y und z) enthält.

Sowohl arrays als auch vectoren können bei mir atomare typen wie auch objekte beinhalten. Bei dir nicht?

edit:
Ok, LOL. Verstehe... "vector"...

Man kann für Referenzen auch r als Präfix nehmen

Ach du meinst den STL-Container vector, ich dachte einen 3D-Vector?

Aber lassen wir das, ich denke auch, dass i für int und so weiter überflüssig sind, aber a, p, r, m_ und g_ finde ich wichtig.

Zitat von »BurningWave«

Ach du meinst den STL-Container vector, ich dachte einen 3D-Vector?

Was für einen grund hätte ich, den in zusammenhang mit nem array zu bringen?

Zitat von »BurningWave«

aber a, p, r, m_ und g_ finde ich wichtig.

Warum a, p und g schlecht sind, hatten wir ja schon. Weils so schön is, klären wir jetzt noch, warum r schlecht ist:
Und das ist ganz einfach. Wenn du eine referenz verwendest, ist die info "const oder nicht const" extrem wichtig. Eigentlich ist diese info sogar wichtiger als die info, dass es eine referenz ist. Dein r bietet also im endeffekt nur nutzlose informationen, kann man also drauf verzichten. Vor allem weil der nächste, der die UN etwas weiter auslegt, dann leicht verwirrt sein könnte...

Zitat von »MasterK«

Was für einen grund hätte ich, den in zusammenhang mit nem array zu bringen?

Das habe ich mich auch gefragt.

Aber dass die UN schlecht ist, ist Geschmackssache, da stimmst du mir hoffentlich zu, dass wir mal einer Meinung sind.

Dachte die Streitfrage "Objekt Orientierung versus Ungarischer Notation" und ob UN mit eben dieser "bricht" hatten wir bereits auf Seite 3 geklärt?