Klasse: Überall "this->" vorkleben?

[Telk]

Hallo liebes Forum,

ich bin gerade an meinem ersten "großen" Hobby Projekt.

Ich habe eine Klasse geschrieben die mir Bilder verwaltet. Jede Instanz repräsentiert ein Bild. Jetzt frage ich mich, ob es sinnvoll ist bei der Zuweisung im Quellcode immer "this->" vor die Variablen zu schreiben auch wenn es vielleicht gar nicht nötig wäre, nur um zu zeigen das es sich tatsächlich auch auf das Objekt bezieht. Was meint ihr?

Lg

[Belli]

Ich meine: Nein.

[Eisflamme]

Definitiv nein. Das sollte auch so erkenntlich sein, wenn der Code nicht viel zu komplex ist. Ich verwende this nur bei Namenskonflikten wie z.B. bei Methoden, die gleichnamige Parameter haben. Ansonsten stört das nur den Lesefluss und ist mehr Schreibarbeit.

Edit: Um keinen neuen Post zu machen: *lynch Skym0sh0*

[Skym0sh0]

Ich schreibs immer wo geht hin. Hilft mir zu verstehen, dass die angesprochene Entität von dem Objekt selbst ist.

Ich doppel-moppel das auch noch indem ich vor jede Membervariable "m_" schreibe:

this->m_recursiveImage;

Aber ist Geschmackssache wie ich finde.

(Hier im Forum lynchen mich eh alle dafür :D)

[Telk]

Danke für den schnellen Input ! Hat mir sehr geholfen.

[dd++ 0]

der Compiler bedankt sich für "this->", es hilft ihm beim name lookup, siehe ISO/IEC 14882:2011 3.4 Name lookup S. 45 - 59

[asc]

Eigentlich bin ich weder ein Freund von einem speziellen Member-Präfix (wie "m_") noch finde ich "this->" sonderlich schön. Wenn aber das Projekt eines von beiden Vorgeben würde, wäre meine Wahl eher "this->".

Ich verwende in privaten Projekten this-> nur bei Namenskonflikten zwischen Übergabeparametern und Membervariablen.

[Nexus]

Ich verwende konsequent mMemberVariable . Ganz selten this-> , wenn ich in Templates auf Basisklassenmember zugreifen muss. Meist sind das dann aber Funktionen...

this->m_memberVariable ist wirklich sinnlos. Etwa gleich wie return (expression); oder if (a == true) . Es macht Ausdrücke unnötig kompliziert und verwirrt Leute.

[Nathan]

Wie schreibt ihr nicht:

if ( (a < 5) == true)
    ;

?
SCNR

@topic:
Ich verwende auch nie this->. Membervariablen enden bei mir mit einem Unterstrich.
position_, count_, etc.

[Eisflamme]

Bei dem _ hatte ich mal den Fehler, dass ich da stehen hatte:

bla = bla;

statt

bla_ = bla;

Wenn ich wüsste, dass der Parameter gleichnamig ist, hätte ich ohne _ das this genommen.

Natürlich eigene Blödheit, aber ich habe eine halbe Stunde oder so nach dem Fehler gesucht, weil der _ so unauffälig ist. Seitdem mag ich das nicht mehr. Klassenmember heißen so wie sie heißen. Seit ich das so mache, hatte ich noch nie Konfusion.

[Nathan]

Eben deshalb verwende ich das ja.
m_variable oder this->variable oder gar this->m_variable stört m.M. nach den Lesefluss.
Da habe ich lieber so ein unauffälliges _.

[Shade Of Mine]

Eisflamme schrieb:

Natürlich eigene Blödheit, aber ich habe eine halbe Stunde oder so nach dem Fehler gesucht

Dein Compiler sollte dich bei soetwas warnen.

[Nexus]

Nathan schrieb:

Eben deshalb verwende ich das ja.
m_variable oder this->variable oder gar this->m_variable stört m.M. nach den Lesefluss.

Darum nehme ich ja mVariable -- gleiche Konvention wie für alle andere Variablen, nur beginnend mit "m"

Nathan schrieb:

Da habe ich lieber so ein unauffälliges _.

Neben der Übersehbarkeit würde mich hier stören, dass der Unterstrich bei Operatoren schnell untergeht.

[Michael E.]

Ich schreibe weder "this->", noch haben meine Membervariablen irgendeine Kennung wie "", "m", "m" oder was auch immer. Hab auch noch nie den Sinn darin gesehen. Als ein Argument für ein Präfix wird gerne verwendet, dass Intellisense nach dem Tippen des Präfix nur noch Member anzeigt. Toll, bis ich "m_" geschrieben habe, hat ich mit Intellisense schon den korrekten Member ausgewählt, wenn ich kein Präfix benutze. Weiterhin soll ein Prä- oder Suffix angeblich die Übersichtlichkeit erhöhen, welche Variablen lokal sind und welche zur Klasse gehören. Nun, meine Scopes sind außer bei schlampig programmierter Write-Only-Software klein genug, dass ich die Übersicht sowieso nicht verliere. Dann gibt es noch das Argument der gleichnamigen Parameter bei Konstruktoren und Settern. Letztere hab ich eigentlich sowieso nicht. Die Konstruktorargumente brauche ich genau einmal zum Initialisieren der Member. Daher bekommen auch die Konstruktorargumente den abschließenden Unterstrich und nicht die Member.

[pluseins]

+1 Michael E., bis auf eins:

Michael E. schrieb:

Die Konstruktorargumente brauche ich genau einmal zum Initialisieren der Member. Daher bekommen auch die Konstruktorargumente den abschließenden Unterstrich und nicht die Member.

Weil ich die Member eigentlich ausschliesslich in der Initialisierungsliste initialisiere, kann ich die Parameter auch genau gleich benennen wie sie.

[dot]

Michael E. schrieb:

...

+1

[Nathan]

Nexus schrieb:

Nathan schrieb:

Eben deshalb verwende ich das ja.
m_variable oder this->variable oder gar this->m_variable stört m.M. nach den Lesefluss.

Darum nehme ich ja mVariable -- gleiche Konvention wie für alle andere Variablen, nur beginnend mit "m"

Ist ja schön und gut.
Ich nutze die Konvention mit_unterstrichen. Da wäre m_ logischerweise notwendig. m_ ist mir jedoch wieder zuviel Tipparbeit. Also nehme ich nur den Unterstrich. Der sollte allerdings wegen Reserviertheit und so ans Ende. Also _.
Und was hast du gegen:

position_.x += speed_ * cur_dir_;

? Ja, ok, position_-> bzw. position_. sieht seltsam aus.
Allerdings ist das für mich die beste Alternative.

[out]

Nathan schrieb:

Also nehme ich nur den Unterstrich. Der sollte allerdings wegen Reserviertheit und so ans Ende.

reserved in any scope:

1. Bezeichner, die '__' enthalten.
2. Bezeichner, die mit '_' beginnen und dann ein Großbuchstabe folgt.

-reserved in global scope:
3) Globale Bezeichner, die mit '_' beginnen.

[Shade Of Mine]

In Sprachen wie Java, Python, JavaScript,... wuerde nie jemand auf die Idee kommen Member speziell zu kennzeichnen.

Lasst die ungarische Notation bitte endlich sterben. Denn das ist nichts anderes als ein ueberbleibsel aus der C Zeit wo wir ungarische Notation als sinnvoll angesehen haben.

[dd++ 0]

C++ wurde entworfen, um Datenabstraktion, objektorientiertes Programmieren und generisches Programmieren zusätzlich zu den traditionellen C-Programmiertechniken mit diesen Einschränkungen zu unterstützen. Es war nicht die Absicht, allen Benutzern einen bestimmten Programmierstil aufzuzwingen.

Bjarne Stroustrup

http://books.google.de/books?id=KW1F9GPUFjkC&lpg=PA24&ots=znYX_J9FEs&hl=de&pg=PA24#v=onepage&q&f=false

... wenn jemand gern ungarisch schreibt, soll er ungarisch schreiben. und wenn jemand gern spanisch schreibt, soll er spanisch schreiben ...