Naming Guide

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?

Swordfish

Cyres schrieb:

[...] Noch nie für nen Kunden gearbeitet?

Vielleicht hot knivil einfach an g'scheit'n Job?

knivil ist afaik ein langzeitstudent der noch nie für eine firma geproggt hat

knivil

Cyres schrieb:

Du willst mir erzählen du musstest deine Klassen nachträglich nie ändern?

Nein, das habe ich nicht gesagt. Aber ich programmiere nicht mit dem Gedanken "Hey das kann ich in Zukunft vieleicht besser und baue schon mal viele Moeglichkeiten ein, weil im Moment weiss ich nicht was genau ich will und vor allem wie ich es will". Zumal das Beispiel eine sehr triviale Aenderung ist, die recht gut (halb)automatisch geschehen kann.

Eisflamme

Also ich weiß nicht, wie gut z.B. VisualAssist diesen Rename kann. Ich habe nur gemerkt, dass das schon dann nicht gut klappt, wenn mehrere unterschiedliche Klassen Attribute/Methoden mit dem gleichen Namen haben. Und das kann ja nun ganz gut vorkommen.

Ich baue auch nicht alles mit dem Verdacht, dass man da Mal was ändern könnte. Macht man das überall und konsequent, hat man sein Projekt schnell overengineered. Aber Setter/Getter sind für mich einfach Standard aus all den möglichen Änderungs/Erweiterungsmöglichkeiten, die sich genau an der Stelle ständig ergeben. Für mich ist das auch ein Prinzip, das einfach zur Kapselung an sich gehört. Neben Eventhandlung, Logging, abgeschafftem Attribut kann man auch noch überlegen, dass sich der Typ vielleicht ändert und man eine Methode anbietet, die automatisch konvertiert.

Das hatte ich nämlich letztens: Ich hatte einen String, der erst nur dekorativen Charakter hatte. Später sah ich aber, dass man da doch noch gut was drumherum abstrahieren konnte, also habe ich den durch eine Klasse ersetzt. Jetzt gab es aber Getter und Setter für den String hinter dem abstrakten Objekt. Rasch die Getter und Setter so abgebaut, dass die eben auch die Konvertierung (keine besonders komplizierte, aber immerhin) übernehmen und den Rest des Programms musste ich nicht ändern.

Hätte ich einfach öffentlichen Zugriff auf die Attribute gewährt, na ja... um Codeduplikation zu vermeiden, hätte ich eben dann korrekte Setter und Getter eingebaut.

Ich weiß nicht, ich bin ja auch gegen Prinzipsachen, aber mir haben publike Attribute zu viele Freizüge. Klar, keiner hat vorgeschlagen alle öffentlich zu machen, aber es kommt imo wirklich häufig vor, dass man gerade die Teile refactored... Und es tut doch auch nicht weh?

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