Naming Guide

cooky451

SideWinder schrieb:

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

static const
static
const
Rest

Ansonsten sieht die Anordnung bei mir so aus:

class foo
{
  // Typen
public:
protected:
private:
  // Membervariablen
public:
protected:
private:
  // Methoden
public:
protected:
private:
};

Ich schreibe die Membervariablen über die Methoden, weil ich das Gefühl habe, dass diese mir einen schnelleren Überblick über die Klasse verschaffen. [Endlose Diskussion darüber hier einfügen.]
Typen überm Rest finde ich irgendwie natürlicher. public/protected/private sollte selbsterklärend sein. Bei den Methoden sortiere ich
Konstruktoren
Kopierkonstruktoren
Move-Konstruktoren
Destruktor
operator = (copy)
operator = (move)
Restliche Operatoren
Eigenschaftsabfragen (size(), ...)
Restliche const Methoden
Methoden
Statische Funktionen

SideWinder schrieb:

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...

Alles was static ist, ist ja für das Speicherlayout der Objekte egal. Ansonsten muss ich zugeben, halten sich die Klassen in denen ich mir darüber Gedanken mache doch sehr in Grenzen. Üblicherweise sind das dann auch structs. (-> struct ist bei mir alles ohne virtual und mit ausschließlich public Membern.)

Cyres

Ich schreibe auch stets die Variablen in die Klasse nach oben. Wenn jemand die Klasse benutzten will, guckt er in die Dokumentation, aber für das verstehen einer Klasse benötigt man das Wissen über die Variablen.

cooky451 schrieb:

Einfach weil ich .size() lieber mag als .getSize() - und .Size() geht natürlich garnicht.

Ich zum Beispiel finde den STL Coding-Style und dieses ewige get und set furchtbar und nutze darum letztere Schreibweise und würde desshalb gerne wissen warum das "gar nicht geht"?

cooky451

Ich mag's nicht und insbesondere mit dem STL Stil dazwischen (den man ja zwangsläufig ab und an hat wenn man die Standardbibiothek benutzt) sieht es einfach doof aus. Wenn ich ordentliche Argumente dagegen hätte, hätte ich die schon genannt.;)

Nexus

Shade Of Mine schrieb:

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

Normalerweise habe ich auch nur alle Variablen private oder alle public , aber mir fällt gerade ein Beispiel ein, wo das nicht so ist:

class Particle
{
    public:
       Vector position;
       Vector velocity;
       Color  color;
       ...

    private:
       Time   lifetime;
       Time   maxLifetime;
};

Die Lebenszeit (bereits abgelaufene oder maximale) soll nicht nach der Erstellung verändert werden können. Dennoch habe ich keine Setter/Getter genommen, weil Kapselung nicht viel bringt und Code unnötig verkompliziert. Beispiele sind Änderungen von Alpha-Farbwert und Geschwindigkeit:

particle.color.a -= 5;
// vs
Color color = particle.getColor();
color.a -= 5;
particle.setColor(color);

particle.position += particle.velocity;
// vs
particle.setPosition(particle.getPosition() + particle.getVelocity());

Findest du das sehr schlecht?

Zum Thema: unter_striche finde ich nicht allzu gut lesbar, ich verwende sie höchstens aus Kompatibilitätsgründen.

Wenn ich ausnahmsweise einmal Getter und Setter brauche, schreibe ich Funktionen, die Referenzen zurückgeben:

particle.position() += particle.velocity();
// vs
particle.position += particle.velocity;
// vs
particle.setPosition(particle.getPosition() + particle.getVelocity());

Ich kann zwar keine Überprüfung der Zuweisung machen (würde ich das benötigen, hiesse die Funktion nicht position() oder setPosition() sondern move()), aber es gibt mir Freiheiten, wie ich die Klasse organisiere.

Ich könnte die Position zum Beispiel pimplen oder ein privates MovingPoint-Objekt besitzen, das position() und velocity() besitzt.

Und vor allem ist es syntaktisch konsistent mit reinen gettern.

unter_striche finde ich nicht allzu gut lesbar, ich verwende sie höchstens aus Kompatibilitätsgründen.

was_soll_an_unterstrichen_nicht_gut_lesbar_sein ?
unterstricheFindeIchSehrGutLesbarVielMehrAlsCamelCase .

Das einzige Argument ist, dass Namen mit Unterstrichen mehr Zeichen brauchen und ev. einen Tastendruck mehr zum Schreiben benötigen, aber ich finde es ist die Lesbarkeit wert.

Cyres

namser schrieb:

was_soll_an_unterstrichen_nicht_gut_lesbar_sein ?
unterstricheFindeIchSehrGutLesbarVielMehrAlsCamelCase

FürGewöhnlichHatManJaAuchNamenDieNurKurzUndTreffendSindUndNichtElendigLangeSaetze.

Sone

Cyres schrieb:

namser schrieb:

was_soll_an_unterstrichen_nicht_gut_lesbar_sein ?
unterstricheFindeIchSehrGutLesbarVielMehrAlsCamelCase

FürGewöhnlichHatManJaAuchNamenDieNurKurzUndTreffendSindUndNichtElendigLangeSaetze.

Nexus

Ich finde std_style im Zusammenhang mit Operatoren schlechter lesbar.

my_ship->set_direction(enemy_position-my_position);

// vs

myShip->setDirection(enemyPosition-myPosition);

Ausserdem kann man Typen und Variablen/Funktionen nicht direkt unterscheiden. Sowas wie Ship ship; geht nicht, man muss sich ständig künstliche Bezeichner wie current_ship ausdenken, damit sich Variablen- und Typname nicht überdecken.

Zum anderen Problem: Findet ihr Klassen, die sowohl public - als auch private -Member besitzen, problematisch? Wie würdet ihr mein Partikelbeispiel im letzten Post lösen?

cooky451

Nexus schrieb:

Wie würdet ihr mein Partikelbeispiel im letzten Post lösen?

Ich bin zwar nicht gegen public/private Mischung, aber bei dem Beispiel würde ich alles public machen und const Time created + const Time lifetime nutzen, die vergangene Zeit abzuspeichern halte ich für einen ziemlichen Performancekiller..

Nexus

cooky451 schrieb:

bei dem Beispiel würde ich alles public machen und const Time created + const Time lifetime nutzen

Wenn ich die Member const -qualifiziere, verliere ich Wertsemantik. Ich kann Particle -Objekte nicht mehr in std::vector speichern und mit std::remove_if() entfernen.

cooky451 schrieb:

die vergangene Zeit abzuspeichern halte ich für einen ziemlichen Performancekiller..

Warum? Die vergangene Zeit muss meist mehrmals pro Frame abgerufen werden, nämlich von den Affectors. Was bringt es, wenn ich diese jedes Mal wieder neu berechnen muss, statt einmal pro Frame zu aktualisieren?