Member-Prä/Suffix wegen Parameternamen?

Eisflamme

Hi,

ich würde gerne nochmal die Diskussion aufrollen, weil es mich interessiert und ich jetzt Semesterferien habe:

Es gibt ja so diverse Meinungen dazu, ob man Attribute als solche kennzeichnen sollte oder nicht. Falls man es tut, kann man das via m_ Präfix machen oder mit _-Suffix z.B. Ersteres wirkt anscheinend bei manchen Personengruppen "kindisch", aber da weiß ich nicht, ob das noch aktuell ist und wer das so sieht.

Außerdem wird beim m_-Präfix kritisiert, dass automatische Vervollständigung nicht mehr so gut klappt, allerdings kommt VisualAssist damit ja ganz gut zurecht. Das _-Suffix hingegen hat auch diverse Nachteile. Man erkennt nicht rasch, dass es ein Member ist, weil ein _-Suffix eben Mal schnell in einem Zeichensalat verschwindet. Und wenn man Zuweisungen über Setter vornimmt, passiert es Mal schnell, dass man statt bla_ = bla; so was wie bla = bla; schreibt... kann auch ein Tippfehler sein, der ebenfalls schnell untergeht.

Ich würde ja eigentlich gern komplett auf Benennung verzichten, also weder Prä- noch Suffix nutzen. Jetzt stellt sich nur die Frage, wie man gleichnamige Parameter kennzeichnet oder ob man das tut? Hier gibt es ja jetzt auch wieder Möglichkeiten. Man könnte p_ als Präfix nehmen (mit den Nachteilen von m_) oder sich z.B. auch die Mühe machen etwas Passendes davor zu schreiben. Z.B. etwas, das schon darauf hinweist, ob man etwas ersetzt wie "newStuff" oder "alternativeStuff" oder was weiß ich.

Na ja oder man nennt es trotzdem genau gleich, aber arbeitet dann mit this. Dabei ist aber der Nachteil, dass this ungern geschrieben wird, weil es im Normalfall eben unnötig ist. Also hat man manchmal ein this und manchmal eben nicht, was Menschen mit böser Zunge ja als inkonsequent bezeichnen könnten (tun sie das?). Der Vorteil daran ist aber, dass man bei Parameterübergaben genau sieht, wie die Zuweisung geschieht und hier natürlich keinerlei Flüchtigkeitsfehler mehr machen kann ( this->bla = bla; ist weitaus weniger tippfehleranfällig als bla_ = bla; ).

Außerdem hat man beim ctor das Problem mit this nicht, da die Element-Initialisierer schlau sind und wissen, was Attribut und was Parameter ist. Daher fände ich die this->Version eigentlich ganz hübsch, allerdings sieht man sie nirgendwo. Habe ich einen Nachteil übersehen?

Edit: Ups, das sollte ins C++-Forum... kann ja jemand verschieben; denke, für C# und Java könnten Details einen komplett anderen Ausschlag geben.

Eisflamme schrieb:

da weiß ich nicht, ob das noch aktuell ist

Wieso "noch"? Meinst du die Präfixe/Suffixe/ungarische Notation erleben nochmal eine Renaissance?

wer das so sieht.

jeder der was auf sich (seinen code) hält </thread>

Eisflamme

Ich sehe auch in professionellen Codes oft solche Präfixe und ich finde die nicht so schlimm, dass ich deswegen irgend jemanden degradieren würde. Gerade bei Teamarbeit ist so etwas manchmal ja auch hilfreich. Und je nach Sprache sowieso.

Wie gehst Du denn dann bei Parametern um? Nimmst Du die this->Version? Vll. schaue ich mir zu wenig neue, komplexe Projekte an.

cooky451

Eisflamme schrieb:

Ersteres wirkt anscheinend bei manchen Personengruppen "kindisch"

Wenn das ein Gegenargument sein soll kannst du es getrost ignorieren.

Eisflamme schrieb:

Das _-Suffix hingegen hat auch diverse Nachteile.

Sehe ich auch so. Allerdings ist "verschwindet im Zeichensalat" kein Nachteil; wenn man das nicht sieht sollte man entweder den Code neu strukturieren oder zum Augenarzt gehen. Es ist halt aufwendiger zu schreiben. Trotzdem gilt immer noch Lesbarkeit > Schreibbarkeit und deshalb mag ich dieses Suffix.

Eisflamme schrieb:

wie man gleichnamige Parameter kennzeichnet

Die Frage kann man auch dann stellen, wenn man public Member hat. (Die ja keine Pre/Suffixe haben.) Ich mache es dann einfach umgekehrt und mache bei den Parametern ein _ am Ende. Na ja, sehr schön ist das nicht unbedingt, aber wenn der Konstruktor eh nur 3 Zeilen lang ist, ist das auch egal.

@cooky451: also manchmal frag ich mich schon, wass ihr so viel anders macht als ich und dann les ich hier und die schuppen fallen mir von den augen

Eisflamme schrieb:

Ich sehe auch in professionellen Codes oft solche Präfixe

"professioneller Code", was auch immer das sein mag, ist ja auch oft alt or Teil einer alten Codebase mit alten Konventionen, die dann sinnvollerweise auch eingehalten werden.

Wie gehst Du denn dann bei Parametern um? Nimmst Du die this->Version? Vll. schaue ich mir zu wenig neue, komplexe Projekte an.

Dann stell ich mir zuerst die Frage, warum ich 2 Variablen mit gleichem Namen im Scope habe. Wenn ich darauf eine sinnvolle Antwort finde, benutz ich this(./->)

_ Prefix ist in C++ illegal

Eisflamme

cooky451:
Kindisch: Jup, sollte ein Gegenargument sein.

Und Augenarzt na ja... ich habe mich halt Mal vertippt und das _ vergessen. Wenn ich dann in größeren Codeblöcken nach Bugs suche, sehe ich das mit _ eben nicht so schnell. Ich finde schon, dass das ein gewisser Nachteil ist.

gast:
Mit professionellem Code meine ich eben OS-Code, der aber in großem Umfang verwendet wird. Beispielsweise Assimp oder auch diverse 3D-Engines. Mag sein, dass die Konventionen da alt sind. Andererseits sind die Bibliotheken auch keine Jahrzehnte alt; ich weiß nicht, ob die IDEs erst seit wenigen Jahren entsprechenden Komfort bieten.

Zu zwei Variablen im gleichen Scope, habe ich ja schon mein Hauptbeispiel genannt: Setter.

Eisflamme schrieb:

Mit professionellem Code meine ich eben OS-Code, der aber in großem Umfang verwendet wird. Beispielsweise Assimp oder auch diverse 3D-Engines. Mag sein, dass die Konventionen da alt sind. Andererseits sind die Bibliotheken auch keine Jahrzehnte alt; ich weiß nicht, ob die IDEs erst seit wenigen Jahren entsprechenden Komfort bieten.

Also Software wie WebKit, Gecko oder die Unreal Engine sind schon alle ziemlich alt (> 10 Jahre). Und nein, damals waren die IDEs allesamt schrecklich. Und die C++ IDEs sind auch heutzutage nicht viel besser (Visual Studio zumindest).

Zu zwei Variablen im gleichen Scope, habe ich ja schon mein Hauptbeispiel genannt: Setter.

Setter sind wohl eher der Ausnahmefall als der Regelfall in gutem objektorientierten Design. Davon abgesehen sind Setter Methoden in der Regel eh nur 1-2 Zeilen lang, insofern kein Kandidat um über mangelde Übersichtlichkeit zu diskutieren.

Falls du mehr dazu wissen willst lies Clean Code, ist zwar Javalastig, aber die aufgestellten Regeln sind sprachunabhängig.

Eisflamme

Also mit Dependency Injection empfinde ich Setter nicht wirklich als Ausnahme. Dass es wenige Zeilen sind, stimmt. Dennoch stellt sich die Frage, wie man es da handhabt.

Und es gibt auch OS-3D-Engines, die neuerer Natur sind.