spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Was ich bei der ganzen Sache nicht verstehe(ich gehe weiterhin von eingeschränkter UN aus):
Es ist ein Merhaufwand, der bei einmal Eingewöhnen total gering ist.

Mir persönlich läufts auch eiskalt über den Rücken, wenn ich Code wie bei MasterK vor Augen habe. 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. "Der Code ist dann ohnehin schlecht", quatsch ist er nicht. Ich schreibe Code doch nicht auf Basis der ungarischen Notation. "Oh, hey, ich habe gekennzeichnet was Pointer und was Member einer Klasse sind, jetzt kann ich Code schreiben wie ich will."
Das klingt bei einigen teilweise schon nach Paranoia "Die Leute sollen bloß nicht denken, dass ich schlechten Code schreibe!!" - was ist denn schlecht daran, eine kleine extra Notation zu einem Variablennamen zu geben, um direkt Pointer oder Membervariablen zu kennzeichnen? Da ist NICHTS schlechtes dran, höchstens die Empfindung. Ich persönlich freue mich, wenn ich fremden Code lese und da ist der Pointer gekennzeichnet. So kommt sofort "pVar->" anstatt "Var." und somit keine Verwunderung darüber, wieso mir VC++ keine Member/Methoden anzeigt. Es klappt sofort alles und ich kann den Code erweitern/benutzen oder sonstwas.
"m_pv_istr_" oder sonstwas ist schlichtweg overkill, da stimme ich zu. Aber zu sagen "m_p" oder sonstwas ist bei gutem Code unnötig, stimmt nicht.

Also sorry, ich kann die Argumentation gegen "teilweise Ungarische Notation" nicht verstehen, erstrecht nicht den Vorwurf, es breche die Objektorientierung. Gegen "übertriebene" UN allerdings schon, da würde ich ohne Kompromisse sagen, dass es unnötig ist.
Nunja, ich möchte hier jetzt niemanden bekehren. Aber den indirekten Vorwurf "Du verwendest UN, dein Code ist schlecht." finde ich schon etwas unangebracht.
Letztendlich ist es doch eh NUR eine Geschmackssache.

Objekt-Orientierung als solche stellt meines Wissens nach auch gar keine Konvention zur Benennung von Variablen oder Methoden auf. UN kann aber durchaus gegen andere Konventionen stoßen, die im Zusammenhang mit OOP gern genannt werden, die aber eigentlich generell für Programmierung gelten sollten.
Bei ordentlichen anderweitigen Konventionen beim Code-Aufbau wird UN allerdings größtenteils überflüssig und erhöht das Chaos im Code und verschlechtert die Lesbarkeit an sich. UN kann also als Deo für Code-Smell oder generell miesen Code dienen, ist aber dann an sich gar nicht das eigentliche Problem, nicht die Ursache, sondern ein Symptom.
Bitte korrigiert mich, falls das falsch ist.

Zitat von »BlueCobold«

Objekt-Orientierung als solche stellt meines Wissens nach auch gar keine Konvention zur Benennung von Variablen oder Methoden auf. UN kann aber durchaus gegen andere Konventionen stoßen, die im Zusammenhang mit OOP gern genannt werden, die aber eigentlich generell für Programmierung gelten sollten.
Bitte korrigiert mich, falls das falsch ist.

Welche Konventionen wären das denn?

Das wären beispielsweise Benennung von Variablen und Methoden derart, dass sie ihren Zweck preisgeben und/oder aus dem Kontext ersichtlich werden, eine übersichtliche (auch da gibt es mehrere Varianten) Art der Variablen-Deklaration und viele andere.

Zitat von »BlueCobold«

Das wären beispielsweise Benennung von Variablen und Methoden derart, dass sie ihren Zweck preisgeben und/oder aus dem Kontext ersichtlich werden, eine übersichtliche (auch da gibt es mehrere Varianten) Art der Variablen-Deklaration und viele andere.

Und wogegen sollte jetzt ein "m_p" oder "m_" verstoßen? Ich benenne Get/Set Methoden entsprechend(obwohl ich schon versuch sie zu vermeiden), ich benenne Check Methoden entsprechend etc etc etc.(also alles was ich bis jetzt so darüber gelernt habe) Und trotzdem schaffe ich es, vor meinen Membervariablen ein "m_" oder ein "m_p" zu schreiben. Klingt komisch, is aber so .

Ein "m_p_v_istr_" habe ich noch nie geschrieben und werde ich hoffentlich auch nicht

Zitat von »KeksX«

Und wogegen sollte jetzt ein "m_p" oder "m_" verstoßen?

Das frage ich ja auch. Ich finde, dass zumindest "m_" oder "m" eine deutlich schnellere Aufnahme fremden Codes ermöglicht, gerade in Team-Projekten mit Versionsverwaltung, wo man dann doch öfter mal nur schnell einzeln geänderte Zeilen nachlesen will.

@BlueCobold und KeksX:
Genau so sehe ich das auch.

Große Funktionen in viele Kleine aufzuteilen, macht nur die ganze Klasse unübersichtlich, wenn die Teilfunktionen nur einmal aufgerufen werden. Da ist es besser den Code der langen Funktion logisch zu gliedern und zu kommentieren.

Zitat von »KeksX«

Was ich bei der ganzen Sache nicht verstehe(ich gehe weiterhin von eingeschränkter UN aus):
Es ist ein Merhaufwand, der bei einmal Eingewöhnen total gering ist.

Aber letztenendes keinen Nutzen bringt, sondern manch einem missfällt. Daher muss man diese Eingewöhnungszeit gar nicht auf sich nehmen.

Zitat von »KeksX«

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

Also ich bezweifle, dass du dich über anderen Code wirklich freuen würdest. Stell dir mal vor, dir gibt jemand eine 200 Zeilen Funktion und sagt, arbeite mit der...da wirst du sicher Freudenschreie ausstoßen, weil du dich erst mal durch diese unendliche Funktion kämpfen darfst.
Die Funktion von MasterK hingegen liefert mir auf einen Blick alle wichtigen Informationen. Wenn die Funktionsnamen gut gewählt sind, dann weiß ich nach wenigen Blicken(und ohne die zusätzlichen Funktionen überhaupt anzusehen, was die Funktion tun soll und wie genau sie das bewerkstelligt.
Ein frei erfundenes Beispiel:

Natürlich könnte man ohne Probleme alles wichtige in diese Funktion stecken, allerdings ist es so sehr viel übersichtlicher und ich weiß sofort, wie das erstellen eines Objekts ablaufen soll. Außerdem kann man - wenn man sinnvoll aufteilt - bestimmte Funktionen auch an anderen Orten noch verwenden. set_render_options() kann ich beispielsweise auch verwenden, wenn ich zum Beispiel mein Objekt plötzlich verschwinden lassen will oder dererlei Dinge.
Also ich verstehe nicht, warum es dir da kalt den Rücken runter läuft, wenn du geordneten Code siehst.

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. "Der Code ist dann ohnehin schlecht", quatsch ist er nicht. Ich schreibe Code doch nicht auf Basis der ungarischen Notation. "Oh, hey, ich habe gekennzeichnet was Pointer und was Member einer Klasse sind, jetzt kann ich Code schreiben wie ich will."
Das klingt bei einigen teilweise schon nach Paranoia "Die Leute sollen bloß nicht denken, dass ich schlechten Code schreibe!!" - was ist denn schlecht daran, eine kleine extra Notation zu einem Variablennamen zu geben, um direkt Pointer oder Membervariablen zu kennzeichnen? Da ist NICHTS schlechtes dran, höchstens die Empfindung.

Es ist ja auch nichts schlechtes daran derartige Dinge zu kennzeichnen. Es ist eben nur zweckfrei, aber natürlich nichts schlechtes.

Zitat von »KeksX«

Ich persönlich freue mich, wenn ich fremden Code lese und da ist der Pointer gekennzeichnet. So kommt sofort "pVar->" anstatt "Var." und somit keine Verwunderung darüber, wieso mir VC++ keine Member/Methoden anzeigt. Es klappt sofort alles und ich kann den Code erweitern/benutzen oder sonstwas.
"m_pv_istr_" oder sonstwas ist schlichtweg overkill, da stimme ich zu. Aber zu sagen "m_p" oder sonstwas ist bei gutem Code unnötig, stimmt nicht.

Wenn ich fremden Code lese, dann sehe ich sofort, dass dort beispielsweise verwendet wird und dann weiß ich: "Aha object ist ein Zeiger."
Und wenn man wirklich vor hat den Code zu erweitern, dann führt meiner Meinung nach kein Weg daran vorbei mal einen Blick in die Klassendeklaration zu werfen und sich einen Überblick zu verschaffen, wofür die Klasse existiert. Überhaupt sollte man ebendas zuerst tun. Es ist doch völlig irrelevant, was irgendeine Funktion in einer Klasse tut, wenn man sich nicht vorher einen Gesamtüberblick über die Funktionsweise der Klasse verschafft hat. Und wenn man dann einen Blick auf die Deklaration wirft, dann sieht man auch, wie welche Objekte definiert sind(was man sich durchaus mal genau anschauen sollte, um das ganze auch zu verstehen). Wenn man also ohne die Klasse zu kennen, diese einfach verwenden oder erweitern will, so bezweifle ich, dass da wirklich was vernünftiges rauskommen wird.

Zitat von »KeksX«

Also sorry, ich kann die Argumentation gegen "teilweise Ungarische Notation" nicht verstehen, erstrecht nicht den Vorwurf, es breche die Objektorientierung. Gegen "übertriebene" UN allerdings schon, da würde ich ohne Kompromisse sagen, dass es unnötig ist.
Nunja, ich möchte hier jetzt niemanden bekehren. Aber den indirekten Vorwurf "Du verwendest UN, dein Code ist schlecht." finde ich schon etwas unangebracht.
Letztendlich ist es doch eh NUR eine Geschmackssache.

Man behauptet ja nicht, dass dein Code mit ungarischer Notation schlecht ist, sondern hinterfragt ja nur, ob deine Art der Notation wirklich sinnvoll und notwendig ist.

Ja stimmt, wenn ich mir vorher den verwendeten Code "in der Praxis" ansehe sehe ich auch schon, dass object ein Zeiger ist.
Allerdings ist das neben dem "angeblichen" Mehraufwand(wie gesagt, das ist Ansichtssache. Für mich ist da kein Mehraufwand, weils einfach drin ist) und dem Argument "das braucht man in gutem Code nicht" das einzige, was hier gesagt wird.

Ich kann ja soweit gehen und sagen: Natürlich braucht man es nicht, wenn ich ehrlich bin ist es auch genauso. Allerdings ist es schöner, hat in gewissen Situationen schon einen (wenn auch kleinen) Nutzen und wenn man es einmal drin hat ist es imho kein Mehraufwand, sondern genau die gleiche Arbeit wie einen guten Variablennamen zu finden

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?