Ist es eher usus den C++ StdLib/Boost-Weg einzuschlagen oder doch eher Klassen mit Großbuchstaben zu Beginn? Hat sich da schon eine Art Default-NamingGuide durchgesetzt?

class MyType vs. my_type
{
    blubb vs. get_blubb vs. getBlubb vs. GetBlubb
    blubb vs. set_blubb vs. setBlubb vs. SetBlubb
}

MfG SideWinder

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();
  }
};

MfG SideWinder

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

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

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.

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

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

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.

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.

Einzige Ausnahme: alle Variablen sind public.

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?

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

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

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

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

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?

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

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

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.

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?