Verben in Methodennamen klein oder groß?

rüdiger

beim durchgehend alles klein schreiben stört mich nur, dass man manchmal so schöne Klassennamen gewählt hat aber die nicht als Objekt Name nehmen kann

zB.

Foo foo;

operator void

Stimmt, das nervt oft. Andererseits kommt man um die Standardbibliothek ja kaum herum, und std-Stil und "modernen C++-Stil" mischen sieht irgendwie auch immer blöd aus

Bini

Iterator schrieb:

kingruedi schrieb:

Natürlich bringt es nichts, wenn alle sagen "mein Stil ist der beste, du bist ein @#$!>(!FOO*¬@"

Eben... darauf läuft es aber in den meisten fällen immer hinaus

Wenn man im Team arbeitet/arbeiten muß, ist es allerdings absolut notwendig, sich über einen Programmierstil zu einigen. Und diese Einigung ist dann gar nicht so einfach. Also kann so eine Diskussion im Vorfeld schon mal nützlich sein.

Helium

Jedes Objekt hat bekanntlich Eigenschaften und Fähigkeiten. Fähigkeiten sind tätigkeiten und deshalb sollten die Methoden, durch die sie repräsentiert werden auch ein Verb als Namen verwenden. So weit ganz logisch. Starten, Fahren, Bremsen, ... sind beispielsweise alles Fähigkeiten eines Autos. Beispielsweise die Farbe hingegen ist eine Eigenschaft. Soweit sind wahrscheinlich alle einer Meinung.

Ein Auto hat aber keine Fähigkeit seine Farbe anzugeben. Wenn man die Farbe des Autos wissen möchte, geht es nicht um eine Fähigkeit, sondern um eine Eigenschaft. Eigenschaften solltn aber nicht durch Verben repräsentiert werden, da es keine Tätigkeiten sind.

Wäre es deshalb nicht sinnvoll die Methoden, die dazu dienen Eigenschaften abzufragen oder zu verändern tatsächlich ohne set oder get (in irgendeiner belibigen Form) zu verwenden? Die Prüfung, beim Ändern der Eigenschaft innerhalb der von den meisten verwendeten set-Methoden dient ja nur vor Programmier- oder Benutzerfehlern und hat nichts mit dem Modell an sich zu tun. Sie sollten deshalb auch keinen Einfluss auf dei Namensgebung haben.

Mal sehen, was ihr jetzt für Gegenargumente bringt.

Helium schrieb:

Wäre es deshalb nicht sinnvoll die Methoden, die dazu dienen Eigenschaften abzufragen oder zu verändern tatsächlich ohne set oder get (in irgendeiner belibigen Form) zu verwenden? Die Prüfung, beim Ändern der Eigenschaft innerhalb der von den meisten verwendeten set-Methoden dient ja nur vor Programmier- oder Benutzerfehlern und hat nichts mit dem Modell an sich zu tun. Sie sollten deshalb auch keinen Einfluss auf dei Namensgebung haben.

Mal sehen, was ihr jetzt für Gegenargumente bringt.

Ich glaube das Gegenargument was du suchst leitet mehr oder weniger jedes Buch/Tut/WAI ein welches auf OOP eingeht.
Wenn du z.B. die Farbe deines Autos änderst indem du dir direct eine Color-Referenz o.ä. geben lässt und diese manipulierst bist du immer und überall auf dieses Color-Objekt festgelegt.
Mittels get/set kannst du die Color-Klasse einfach austauschen und eine andere nehmen und die getter und setter überladen um von und zur alten Color Klasse zu Konvertieren.
Oder du könntest auf die Idee kommen das du zwar 342000 Autos hast aber nicht mehr als 27 verschiedene Farben und dich dazu entschließen einen Auto-internen Color-Pool anzulegen und nicht mehr jedem Auto seine eigene Farbe sondern einen Pointer auf eine Farbe im Pool mitzugeben.
Usw, usf...

Nulliver

Noch'n Klecks Senf, falls es noch jemand interessiert:
Bei uns hat sich durchgesetzt, alles lokale, private, protected oder sonstwie interne Zeugs mit kleinen Anfangsbuchstaben zu schreiben und alles globale, public oder sonstwie von Außen erreichbare Zeugs mit großen Anfangsbuchstaben.

Auf jeden Fall sollte die Möglichkeit, Groß- und Kleinbuchstaben eine konkrete Bedeutung zu geben, auch sinnvoll genutzt werden. Je mehr "egal" im Code ist, desto mehr Möglichkeiten, sich selbst oder Andere zu überlisten, weil jeder es anders interpretieren kann. Wenn jede Kleinigkeit konkrete Bedeutung hat und man sich bei jedem noch so kleinen Detail des Codierstils fragt "Warum genau so und nicht anders?", so erfordert das nur anfänglich mehr Aufwand, macht sich aber auf die Dauer bezahlt, weil solche nicht ganz nebensächlichen Informationen konzentrierter und damit schneller erfaßbar und in der Routine quasi unterbewußt wahrnehmbar bereitgestellt werden. Alles nur eine Frage der Disziplin ...

Nulliver

Noch eine Alternative zu Get/Set-Methoden: Wenn der betreffende Variablentyp einen bestimmten Wert zuläßt, der als "undefiniert" oder "ungültig" betrachtet werden kann, bietet sich eine Kombination von Get() und Set() an in einer Funktion mit dem "undefinierten" Wert als Default-Parameter. Wenn diese Funktion ohne expliziten Parameter aufgerufen wird, gibt sie lediglich den aktuellen Wert zurück, wirkt also als Get(). Wird ein definierter Wert übergeben, wirkt die Funktion als Set() und gibt den vorherigen Wert zurück. Hat den Vorteil, das der Caller sich diesen vorherigen Wert merken und bei Bedarf den ursprünglichen Zustand wiederherstellen kann. Alles mit einer einzigen Funktion.

Walli

Ist aber nicht immer zu empfehlen weil es die Performance unnötig runterziehen kann.

Helium

Ich glaube das Gegenargument was du suchst leitet mehr oder weniger jedes Buch/Tut/WAI ein welches auf OOP eingeht.
Wenn du z.B. die Farbe deines Autos änderst indem du dir direct eine Color-Referenz o.ä. geben lässt und diese manipulierst bist du immer und überall auf dieses Color-Objekt festgelegt.
Mittels get/set kannst du die Color-Klasse einfach austauschen und eine andere nehmen und die getter und setter überladen um von und zur alten Color Klasse zu Konvertieren.
Oder du könntest auf die Idee kommen das du zwar 342000 Autos hast aber nicht mehr als 27 verschiedene Farben und dich dazu entschließen einen Auto-internen Color-Pool anzulegen und nicht mehr jedem Auto seine eigene Farbe sondern einen Pointer auf eine Farbe im Pool mitzugeben.
Usw, usf...

@finix und auch die anderen: Könntet ihr meine Nachricht vielleicht erstmal durchlesen, bevor ihr darauf antwortet? Oder habe ich mich so unklar ausgedrückt. Ich habe nie davon gesprochen die Variablen, die die Eigenschaften repräsentieren öffentlich zugänglich zumachen. Natürlich bleiben Sie weiterhin nur durch Methoden zugänglich.

Um mich selbst zu zitieren:

Wäre es deshalb nicht sinnvoll, Methoden, die dazu dienen Eigenschaften abzufragen oder zu verändern tatsächlich, ohne set oder get (in irgendeiner belibigen Form) [im Namen] zu verwenden?

(editiert zur besseren Verständlichkeit)

Helium schrieb:

(...) Ich habe nie davon gesprochen die Variablen, die die Eigenschaften repräsentieren öffentlich zugänglich zumachen. Natürlich bleiben Sie weiterhin nur durch Methoden zugänglich.

Das ändert nicht viel, zumindest nicht in Bezug auf den schreibenden Zugriff. Z.B. den Farbpool im letzten Bsp. könntest du nicht einfach so realisieren.
Und du wärst immer noch überall auf die spezielle Farb-Klasse festgelegt.

Marc++us

Nulliver schrieb:

Noch eine Alternative zu Get/Set-Methoden: Wenn der betreffende Variablentyp einen bestimmten Wert zuläßt, der als "undefiniert" oder "ungültig" betrachtet werden kann, bietet sich eine Kombination von Get() und Set() an in einer Funktion mit dem "undefinierten" Wert als Default-Parameter. Wenn diese Funktion ohne expliziten Parameter aufgerufen wird, gibt sie lediglich den aktuellen Wert zurück, wirkt also als Get(). Wird ein definierter Wert übergeben, wirkt die Funktion als Set() und gibt den vorherigen Wert zurück. Hat den Vorteil, das der Caller sich diesen vorherigen Wert merken und bei Bedarf den ursprünglichen Zustand wiederherstellen kann. Alles mit einer einzigen Funktion.

Uah. Das gefällt mir gar nicht.

Die Funktion hat damit (unter dem gleichen Namen) zwei unterschiedliche Verhaltensweisen. Es ergibt sich zudem, daß dann das tatsächliche Verhalten einer Funktion nur noch(!) aus den Werten der Variablen erkennbar ist. Steht im Code:

foo.setValue(eineVariable);

so weiß ich nun nicht mehr, ob ich ein get oder set habe, solange ich den Wert von eineVariable nicht kenne.

Folgerung 1 daraus: Ihr macht in Eurem Team kein Codereading, sonst wäre Euch das schon (negativ) aufgefallen.

Folgerung 2: in Eurem Team arbeiten sich nicht oft fremde Entwickler neu ein, sonst wäre Euch schon aufgefallen, daß Ihr das Gebot der "Erwartungskonformität" verletzt (vereinfacht: eine Funktion soll das machen, was ihr Name sagt).

Nachteil in Bezug auf die Performance:

Durch die zusätzlich notwendig if-Abfrage wird der Code langsamer. Durch den zusätzlichen Parameter wird der Code langsamer.

Nachteil in Bezug auf die Programmiersprache:

Eure Vorgehensweise entstellt die Möglichkeiten von Funktionsüberladung.

Den genannten Vorteil, daß man sich als Aufruf den alten Wert merken kann lasse ich nicht als Vorteil gelten - eine Variante wie hier:

int setVal(int newVal)
{
   int r = m_val;
   m_val = newVal;
   return r;
}

würde dies ebenfalls bieten.

Unschön weiterhin, daß dies eben nur für bestimmte Typen geht - z.B. kann man es für bool nicht machen, für double übergibt Ihr etwa NaN?