Eigene Instanz übergeben
-
manni66 schrieb:
Ich würde mir zunächst Gedanken um das unsinnige C in CTest machen ...
Verbesserungsvorschläge?
-
Du meinst, ob du die Namen von Membervariablen mit m_ prefixen sollst?
Das wird durch den Styleguide des Unternehmens oder Teams vorgegeben, in dem man arbeitet. Und wenn nicht, ist es Geschmackssache.
Meine Privatmeinung ist: Grundsätzlich sind Prefixe unnötig, Ausnahmen bestätigen die Regel. Begründung:
* Leichter lesbar ist der Code auf jeden Fall ohne dieses m_lpcsz-Gedöns.
* Leichter schreibbar auch.
* Geprefixte Namen sind Überbleibsel aus den 90er Jahren; besonders Microsoft hat hier viel Unheil angerichtet mit seiner Ungarischen Notation, die einfach nicht totzukriegen ist. Moderne IDEs wissen jederzeit, für welche Art Dingens (Membervariable, Stackvariable, Funktion, Datentyp etc.) ein Bezeichner steht, und zeigen das durch Syntax-Highlighting oder bei Mouse-Over völlig ausreichend an. Editoren, die das nicht können, gehören auf den Müll.
* Wird der Typ einer Variablen geändert, dann muss bei geprefixten Namen auch der Name angepasst werden, sonst sind Name und Typ nicht mehr konsistent.
* Auch Auto-Completion wird eher umständlicher, wenn alle Bezeichner gleich anfangen.
-
Uff du hast es ziemlich auf den Punkt gebracht.
Mein jetztiges Spiel programmiere ich auch mittels Ungarische Notation.
Jetzt schäm ich mich fast
-
-
manni66 schrieb:
Ich würde mir zunächst Gedanken um das unsinnige C in CTest machen ...
hahaha "unsinnig". so ein quatsch. C/I/S/E hat natürlich seine berechtigung. bei p/i/c und dem zeug bei variablen sehe ich kritik ein.
-
manni_666 schrieb:
manni66 schrieb:
Ich würde mir zunächst Gedanken um das unsinnige C in CTest machen ...
hahaha "unsinnig". so ein quatsch. C/I/S/E hat natürlich seine berechtigung. bei p/i/c und dem zeug bei variablen sehe ich kritik ein.
I (für interface) halte ich für berechtigt, um Schnittstellen sichtbar von Klassen abzugrenzen. In C++ ist das leider nur durch Bezeichner-Konventionen möglich, weil Klassen und Interfaces syntaktisch dasselbe sind.
Die anderen (C für class, S für struct und E für enum) halte ich für verzichtbar. Kannst du Argumente dagegen nennen?
-
Printe schrieb:
manni_666 schrieb:
manni66 schrieb:
Ich würde mir zunächst Gedanken um das unsinnige C in CTest machen ...
hahaha "unsinnig". so ein quatsch. C/I/S/E hat natürlich seine berechtigung. bei p/i/c und dem zeug bei variablen sehe ich kritik ein.
I (für interface) halte ich für berechtigt, um Schnittstellen sichtbar von Klassen abzugrenzen. In C++ ist das leider nur durch Bezeichner-Konventionen möglich, weil Klassen und Interfaces syntaktisch dasselbe sind.
Die anderen (C für class, S für struct und E für enum) halte ich für verzichtbar. Kannst du Argumente dagegen nennen?
S sagt mir es handelt sich lediglich um einen "container" für daten. wahrscheinlich keine getter/setter, dafür direkter zugriff auf die member.
wenn ich eine funktion sehe, die "Type x" als parameter hat, kann das ein template type sein, ein typedef oder macro. "EType" würde mir direkt genaueres sagen.
das C halte ich vor allem für einen konsequent schritt zur einheitlichkeit und somit weniger umdenken.natürlich kann man auch alles weglassen und namen wie "window_mousehandler_callback_interface" nutzen
-
manni_666 schrieb:
S sagt mir ...
"EType" würde mir ...Gut, wenns dir hilft. Ich lass mir da gern von meiner IDE helfen, die sagt mir zu jedem Datentyp sofort, was es ist. "Und was ist, wenn du die IDE mal nicht da hast" lasse ich nicht gelten - die habe ich immer da, die ist nämlich Open Source.
das C halte ich vor allem für einen konsequent schritt zur einheitlichkeit und somit weniger umdenken.
Was konsequent und einheitlich ist, kommt stark auf den Standpunkt an. Wenn das das einzige Argument für das C ist, kann ich nur sagen: Nicht überzeugend.
Mich störts, wenn in meinem Klassen-Browser alles mit C anfängt. Als ob ich zu doof wäre, zu merken, dass das Klassen sind ...
natürlich kann man auch alles weglassen und namen wie "window_mousehandler_callback_interface" nutzen
Viel zuviele Wörter. Mindestens window und callback sind überflüssig. Ich würde IMouseHandler oder IMouseEvent oder etwas in der Art vorschlagen.
-
Printe schrieb:
Ich würde IMouseHandler oder IMouseEvent oder etwas in der Art vorschlagen.
Epic fail.
Ein Handler und ein Event sind ja wohl komplett was anderes.
-
hustbaer schrieb:
Ein Handler und ein Event sind ja wohl komplett was anderes.
Wenn geklärt ist, was ein "window_mouse_callback_blablubb" eigentlich sein soll, kann man sich ja für das richtige entscheiden.
Epic fail.
Und wenn schon. Hier ist dein Fisch. <:)))><
