Verben in Methodennamen klein oder groß?

Marc++us

Die weitgehend übliche Regel: Namen von Typen, Klassen, Enums, Strukturen beginnen mit einem großen Buchstaben, alle anderen Bezeichner mit einem Kleinbuchstaben. Demnach werden also auch Instanzen mit einem Kleinbuchstaben begonnen:

ObjektKlasse einObjekt_;

HumeSikkins

Die weitgehend übliche Regel: Namen von Typen, Klassen, Enums, Strukturen beginnen mit einem großen Buchstaben, alle anderen Bezeichner mit einem Kleinbuchstaben

Genau daran versuche ich mich zu halten.
Nur das Enums bei mir nicht immer einheitlich sind. Hängt von ihrer Bedeutung ab. Wenn ich den enum-Hack verwende, kann ein enum auch mal klein beginnen.
Ansonsten sind die Konstanten bei mir häufig komplett groß (-> z.B. Fehlercodes). Allerdings muss ich gestehen, dass ich nach wie vor in der Stil-Such-Phase bin.

rüdiger

Marc++us schrieb:

Und es ist auch irgendwie semantisch verzerrend - mir geht dabei die "Tätigkeit" im Namen verloren. Angenommen, das set besteht aus mehr als nur einem reinen member = wert. Dieser zusätzliche Vorgang (z.B. Wert prüfen) versteckt sich dann hinter einem foo.laenge(5);. Da muß man ganz genau die Klassendeklaration kennen, um zu wissen was hier passiert.

Also ich seh das so, dass mir egal ist, was im Hintergrund durchgeführt wird beim setzen. Solange der einfach die Variable setzt (oder eine Exception schmeißt). Ich weiss aber auch nicht, was da ein set vor dem Namen helfen soll und die Prüfung wird ja idr. per assert im Debug Modus durchgeführt.

Wenn mehr passiert als nur das setzen, dann werd ich die Funktion auch umbenennen! (aber dann in einen noch besser treffenden Namen als setFoo)

Allerdings muss ich gestehen, dass ich nach wie vor in der Stil-Such-Phase bin.

Merkt man. In deim C++ 2 HTML Konverter Projekt wechselst du deinen Stil ja dauernd.

Helium

Nur das Enums bei mir nicht immer einheitlich sind. Hängt von ihrer Bedeutung ab. Wenn ich den enum-Hack verwende, kann ein enum auch mal klein beginnen.

Du benennst enums beim enum-Hack?

class Foo {
public:
   enum bar {quer=...};
};

Das ist interessant. Und waum da dann klein? Einfach so?

Ansonsten sind die Konstanten bei mir häufig komplett groß (-> z.B. Fehlercodes). Allerdings muss ich gestehen, dass ich nach wie vor in der Stil-Such-Phase bin.

Da habe ich auchmal gemacht. Aber inzwischen werden nurnoch Makros komplett großgeschreiben. Das ist IMHO eindeutiger. Vielleicht einfach mal ausprobieren.

Und zu der set- und get-Geschichte: ich verwende set_ und get_, da Funktionen und Methoden bei grundsätzlich mit Verben beginnen.
Allerdings brauche ich solche Methoden erlich gesagt recht selten. Sind meine Designs so seltsam?

Aber bitte keine Disskusion darüber anfangen, ob einzelne Worte dadruch getrennt werden sollen, dass Sie groß beginnen oder durch einen Unterstrich. Das hatte ich jetzt schon mehrmals in anderen Foren und fürt grundsätzlich zu nichts.

rüdiger

also ich verwende keine Macros, deswegen sind konstanten bei mir idr. komplett groß. Der Rest ist aber klein geschrieben

HumeSikkins

@Helium
enum-Hack:
Benutzung einer unbenannten enum zur Simulation statischer Integralen-Konstanten innerhalb einer Klasse bei Compilern die selbige nicht unterstützen:

class Foo
{
static const int maxSize = 10;
...
};

Da dies nicht auf allen Compiler funktioniert, nimmt man hier dann ein enum:

class
{
enum {maxSize = 10};
};

und genau in diesen Situationen sehen meine enum-Konstanten genauso aus, wie (Member-)Variablen auch.

<edit>Ah. Jetzt verstehe ich deine Frage. Nein ich benenne die enums natürlich nicht. Mein Fehler. Was ich meinte war die Benennung der Konstanten</edit>

DrGreenthumb

Ich hab mal eine zeitlang komplett alles klein geschrieben (wie in der stl) und fand das vom Programmieren und lesen her noch am angenehmsten. Leider hat da der Compiler öfter rumgemuckt

SideWinder

DrGreenthumb schrieb:

Ich hab mal eine zeitlang komplett alles klein geschrieben (wie in der stl) und fand das vom Programmieren und lesen her noch am angenehmsten. Leider hat da der Compiler öfter rumgemuckt

In wie fern hatte der an diesem Stil etwas auszusetzen?

MfG SideWinder

DrGreenthumb

gab öfter Namenskonflikte.. das hat genervt.

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.