Naming Guide

SideWinder

Wenn du Getter&Setter hast, dann überladest du die Funktion oder heißen deine Setter dann doch set_blubba()? Datentypen alle kleingeschrieben?

MfG SideWinder

cooky451

Getter und Setter vermeide ich wenn möglich. Bzw. Getter sehe ich mehr als Eigenschaftsabfrage (siehe .size()). Wenn man eh vollen Zugriff hat, überlege ich mir auch die Variable gleich public zu machen. Ansonsten halte ich mich an die Standardbibliothek. (Siehe z.B. http://en.cppreference.com/w/cpp/numeric/complex/real) Aber wie gesagt, insbesondere reine Setter habe ich eigentlich so gut wie nie.

Datentypen schreibe ich (wie alles andere auch) klein. Nur Templateparameter schreibe ich groß.

@cooky451: Wie willst du das Scott beibringen?

Cyres

cooky451 schrieb:

Wenn man eh vollen Zugriff hat, überlege ich mir auch die Variable gleich public zu machen.

Und wie realisierst du Plausibilitätsprüfungen? Wie realisierst du Dinge wie Benachrichtigungen? (z.B. notifyObservers, emit foobar, propertyChanged)

Attribute haben private zu sein, außer es sind Konstanten. Es gibt zwar häufig Fälle, wo man es nicht braucht, aber das führt zu Inkonsistenz im Projekt, manchmal brauchst du einen Methodenaufruf, manchmal einen direkten Attributverweiß.

Zum Topic, ich benutze für Methoden und Funktionen eigentlich lower-camel-case, wie zum Beispiel in Java, aber anstelle von getFoo() und setFoo(int) überlade ich lieber foo() const mit foo(int).
Klassen und Verwandte schreibe ich Upper-Camel-Case.
Konstanten werden bei mir groß geschrieben mit _ als Worttrenner.

cooky451

Cyres schrieb:

cooky451 schrieb:

Wenn man eh vollen Zugriff hat, überlege ich mir auch die Variable gleich public zu machen.

Und wie realisierst du Plausibilitätsprüfungen?

Das nennt man dann nicht vollen Zugriff.

Cyres schrieb:

Wie realisierst du Dinge wie Benachrichtigungen? (z.B. notifyObservers, emit foobar, propertyChanged)

Garnicht wenn ich es nicht brauche.
Du schreibst ernsthaft alle deine Klassen mit dem Gedanken im Hinterkopf, jemand könnte die mal "observen" wollen? Geil.

"Wenn es sinnvoll ist X zu machen, dann mache ich das."
"Hey! Hier habe ich Situation Y und Z in der X nicht sinnvoll ist!!1!"

Ne.. so läuft das nicht. Du musst schon argumentieren, warum das nie sinnvoll ist.

Cyres

cooky451 schrieb:

Cyres schrieb:

cooky451 schrieb:

Wenn man eh vollen Zugriff hat, überlege ich mir auch die Variable gleich public zu machen.

Und wie realisierst du Plausibilitätsprüfungen?

Das nennt man dann nicht vollen Zugriff.

Cyres schrieb:

Wie realisierst du Dinge wie Benachrichtigungen? (z.B. notifyObservers, emit foobar, propertyChanged)

Garnicht wenn ich es nicht brauche.
Du schreibst ernsthaft alle deine Klassen mit dem Gedanken im Hinterkopf, jemand könnte die mal "observen" wollen? Geil.

Habe oben noch was editiert:

Cyres schrieb:

Es gibt zwar häufig Fälle, wo man es nicht braucht, aber das führt zu Inkonsistenz im Projekt, manchmal brauchst du einen Methodenaufruf, manchmal einen direkten Attributverweiß.

cooky451

Cyres schrieb:

Habe oben noch was editiert:

Cyres schrieb:

Es gibt zwar häufig Fälle, wo man es nicht braucht, aber das führt zu Inkonsistenz im Projekt, manchmal brauchst du einen Methodenaufruf, manchmal einen direkten Attributverweiß.

Ich nutze auch Templates und "normale" Funktionen in einem Projekt, das wird deshalb nicht gleich inkonsistent. Aber da du jetzt wenigstens ein sinnvolles Argument gebracht hast kann ich den Kopf ja wieder vom Tisch nehmen und jeder kann machen was er für richtig hält.

Sone

Na, ich geb mal meine Haltung zu Benennung ab:

Klassennamen groß.
Funktionsnamen immer klein, seien es globale oder Membermethoden
Variablennamen fangen in der Klasse mit dem Präfix m an, und sind dann immer groß. Lokale oder globale Variablen fangen immer klein an.
Jetzt kommt eine Ausnahme. Membervariablen, die nicht gekapselt sind, also als public markiert, werden wie lokale Variablen benannt.
Setter oder getter mach ich durch Überladung (wie std::stringstream::str() ). Bspw.:

uint8_t size() const;
void size(uint8_t const);

Sone

cooky451 schrieb:

Wenn man eh vollen Zugriff hat, überlege ich mir auch die Variable gleich public zu machen.

Ich dachte schon, mit der Haltung wäre ich alleine! thx

Cyres

cooky451 schrieb:

Aber da du jetzt wenigstens ein sinnvolles Argument gebracht hast kann ich den Kopf ja wieder vom Tisch nehmen

Da bin ich ja beruhigt, sonst wird das tippen für dich zur Herausforderung

Wenn man für sich selber programmiert oder das ganze Team den Stil verfolgt sollte das auch nicht zum Problem werden.

knivil

Attribute haben private zu sein, außer es sind Konstanten

Quatsch.

Aber hey, wenn man sonst keine Probleme hat, dann kann man sich auch ueber die Benamung auslassen. Im Moment folge ich dem STL-Vorbild.

Shade Of Mine

Ich würde nie eine Variable public machen. Nie nie nie nie.

Einzige Ausnahme: alle Variablen sind public.

knivil

In meinem aktuellen Projekt ist das eher die Regel, als die Ausnahme, da viele Klassen fuer geometrische Objekte benoetigt werden. Punkt, Strecke, Strahl, Kreis, Rechteck, ... fuer 2, 3 und 4 Dimensionen.

Shade Of Mine

knivil schrieb:

In meinem aktuellen Projekt ist das eher die Regel, als die Ausnahme, da viele Klassen fuer geometrische Objekte benoetigt werden. Punkt, Strecke, Strahl, Kreis, Rechteck, ... fuer 2, 3 und 4 Dimensionen.

Klar - aber ein Punkt hat 2-3 public Variablen und keine private Variable. Korrekt?

knivil

Ja!

SideWinder

Gibt es irgendwelche Besonderheiten in C++ bzgl. Member-Variablen-Platzierung in der Klasse? Oben? Unten? static const oben oder unten?

Da ja die Reihenfolge der Member-Variablen untereinander ja für die Initialisierung wichtig ist, spielt vielleicht auch die sonstige Anordnung (eben bspw. in Bezug auf static const) eine Rolle...

MfG SideWinder

Eisflamme

Ich finde, Attribute müssen auch private sein. Nicht nur im Bezug auf ein Event-System oder Plausibilitätsprüfungen, sondern auch im Bezug auf irgendeine andere Erweiterung/Änderung. Sagen wir, irgendein Attribut war vorher einfach festgelegt, jetzt strukturiert man aber um und merkt, dass es redundant ist, also löscht man es... wenn man eine Methode hat, kann die jetzt eben Mal schnell aus den anderen Attributen den Wert berechnen und zurückliefern, kein Problem.

Wenn das Attribut public war, dann hat man die Möglichkeit nicht. Dann muss man es drin lassen oder überall, wo es gebraucht wird, ersetzen. Darum finde ich öffentliche Attribute für Klassen nicht gut.

@Topic:
Ich schreibe Klassennamen groß und Methodennamen auch groß. Private Methoden/Funktionen mache ich hingegen klein.

Ich glaube, für die Anordnung von Variablen ist das völlig egal. Ich gewöhne mir mittlerweile an, den public Teil oben zu machen und den private Teil darunter, einfach damit man beim Öffnen der Headerdatei zuerst die Schnittstelle und dann die Interna sieht. Statisches kommt bei mir auch im jeweiligen Block immer nach oben. Wenn ich private Methoden habe, stelle ich die über die jeweiligen Attribute (mit der gleichen Begründung wie public/private, dass private Methoden eben für mich "abstrakter" als die Attribute sind).

cooky451 schrieb:

Wirklich durchgesetzt hat sich nichts. Mir scheint der "Java-Weg" (so nenne ich ihn mal) ist beliebter. Ich tendiere momentan jedoch eher zur STL/boost Benennung. Einfach weil ich .size() lieber mag als .getSize() - und .Size() geht natürlich garnicht.

Edit: Also so
template <typename ForwardIterator, std::size_t BufSize>
class foo : basic_bar<ForwardIterator, BufSize>
{
  std::vector<char> blocks_;

public:
  foo(std::size_t multi)
    : block_(BufSize * multi)
  {}

  std::size_t size() const
  {
    return blocks_.size();
  }
};

finde ich auch besser, das wirkt dann eher so, als wäre size tatsächlich ne eigenschaft des objektes(was es ja auch ist) und nicht nur irgendeine random variable

knivil

spielt vielleicht auch die sonstige Anordnung

Wegen padding vielleicht.

jetzt strukturiert man aber um und merkt

Ich schreibe meine Quelltexte aber nicht in Bezug auf "vielleicht will ich das ja irgendwann so oder so machen" .

Cyres

knivil schrieb:

spielt vielleicht auch die sonstige Anordnung

Wegen padding vielleicht.

jetzt strukturiert man aber um und merkt

Ich schreibe meine Quelltexte aber nicht in Bezug auf "vielleicht will ich das ja irgendwann so oder so machen" .

Du willst mir erzählen du musstest deine Klassen nachträglich nie ändern? Noch nie für nen Kunden gearbeitet?