C:Style

[Kerli]

So, ich hab jetzt einmal einen Punkt mit Wächtern eingebaut. Kritik ist wie immer erwünscht

[Xin]

Da sind noch reichlich Überschriften ohne Text drin, daher: Push

Weiterhin könnte man die Stil-Kapitel, wie C:Pre in Unterkapitel unterteilen (Namensraum C:Style?).
PS: In C:Switch findet sich noch ein Part für Magic Numbers, der da auch rein könnte und switch könnte dann dorthin verweisen.

[cloidnerux]

Hab noch ein wenig hinzugefügt.
Änderungen erwünscht.

[Xin]

HINWEIS:

Der Artikel liegt inzwischen in c:style

[Xin]

Ich habe beim Lesen noch ein paar Änderungen eingepflegt und was zur Einrückung ergänzt.
Ansonsten den Link zum Diskussionsfred aktualisiert.

Da sind aber tatsächlich noch viele leere Überschriften. ^^

[cloidnerux]

So, diesmal etwas zur Namensgebeung erzält.
Ein Problem, das sich uns in diesem Wikiartikel stellt, ist, dass wir keinen "Standard"-Style haben und jeder seinen eigenen Styl als den besten ansehen wird.
Daher wäre es wohl sinnvoll, wenn wir einen einheits Styl für das Wiki einführen würden, an dem sich alle Code-Beispiele halten müssten, sodass es nicht zu einem zu großem Code wirr war kommt.
Ein Beispiel wie das Aussehen könnte, habe ich unter http://aeris.a-server.tk/index.php/Code-Design_Regeln für das Aeris-Projekt zusammengestellt.

[Kerli]

Daher wäre es wohl sinnvoll, wenn wir einen einheits Styl für das Wiki einführen würden, an dem sich alle Code-Beispiele halten müssten, sodass es nicht zu einem zu großem Code wirr war kommt.

Das wäre sicher sinnvoll. Ich habe es einmal etwas zusammengeschrieben, so wie ich es verwende. Diese Standards basieren einerseits auf den Codingstandards von der Uni und andererseits auf eigenen Erfahrungen und fremden Programmen. Bis jetzt hat er sich zumindest gut bewährt, auch wenn noch nicht alle Regeln drinnen stehen...

Ein Beispiel wie das Aussehen könnte, habe ich unter http://aeris.a-server.tk/index.php/Code-Design_Regeln für das Aeris-Projekt zusammengestellt.

Irgendwie gefällt mir bei dir die Benennung von Variablen und Funktionen nicht sehr. Was machst du denn wenn auch noch typedefs, Klassen, Strukturen oä. dazu kommen, bzw. wie unterscheidest du Membervariablen von Parametern und lokalen Variablen?

[cloidnerux]

Was machst du denn wenn auch noch typedefs, Klassen, Strukturen oä. dazu kommen, bzw. wie unterscheidest du Membervariablen von Parametern und lokalen Variablen?

Naja, ich habe es bisher immer als störend empfunden, wenn ich immer name_s oder iwas_t schreiben musste, da es für mich weder übersichtlicher noch einfacher zu verstehen war. Treffende Namen waren bisher immer hilfreicher.
Zum anderen, bin ich ein wenig von der Visual Studio IntelliSense geprägt, die mir anzeigt was Memebervariable ist und was nicht.
Ich würde jezt keine Membervariable mit dem Namen "zeahler" anlegen, aber eine lokale Variable.
Im Endeffekt kommt es wohl darauf an, was man gewohnt ist.

[Xin]

Irgendwie gefällt mir bei dir die Benennung von Variablen und Funktionen nicht sehr. Was machst du denn wenn auch noch typedefs, Klassen, Strukturen oä. dazu kommen, bzw. wie unterscheidest du Membervariablen von Parametern und lokalen Variablen?

Das Thema interessiert mich sehr.

Ich habe folgende Konvention:
Lokale Variablen/globale Funktionen werden klein geschrieben. (int i; initProgramm())
Typnamen und Typmember werden groß geschrieben. (Typname->TypMember)

Ich verwende keine Unterstriche, keine Affixe. Konstanten sind bei mir Member eines Konstanten-Typs. Das Token von if z.B. heißt bei mir "Key::If" und ist eine Konstante vom Typ Key.
Das funktioniert sehr gut, bis an eine Stelle: Datentypen bezeichnen in der Regel die Daten, die sie enthalten. So bezeichnet der Datentyp TypeSequence bei mir den Datentyp einer Variablen.
Innerhalb einer Variablen möchte ich also nun auf die TypeSequence zugreifen:

Code: Alles auswählen

class Variable
{
  TypeSequence TypeSequence;
}

Und schon sind die Mißverständnisse da. Jetzt möchte ich die Membervariable eigentlich nicht anders nennen, weil der Name natürlich vorgibt, was darin enthalten ist - das gilt für den Typnamen genauso wie für den Namen der Member.
Ansonsten habe ich mit meiner Konvention keine Probleme.

Ich habe durchaus Lösungen für das Problem, indem ich deutlich mehr über Vererbung löse. Das Konzept wäre allerdings nachträglich ins Framework einzupflegen und nur beschränkt sinnvoll nutzbar in C++. Kurz: Es wäre eine halbgare Lösung.
Hier suche ich immernoch sinnvolle Alternativen.

[Kerli]

Das Thema interessiert mich sehr.

Ja, es ist auch nicht wirklich leicht etwas gutes zu finden. Aber man entwickelt sich weiter. Wenn ich mir heute einen Code von mir von vor ein paar Jahren anschaue, dann denke ich mir, wie habe ich das nur so formatieren können

Lokale Variablen/globale Funktionen werden klein geschrieben. (int i; initProgramm())

Und was ist wenn die Variablen aus mehr als nur einem Wort bestehen?

Typnamen und Typmember werden groß geschrieben. (Typname->TypMember)

Da unterscheide ich lieber nach Funktion und Variable. Memberfunktionen schreibe ich so wie du globale Funktionen schreibst, weil das sie Member sind erkennt man ja sowieso an der Klasse davor (Typname->memberFunction). Und Variablen schreibe ich eigentlich immer klein mit Unterstrichen getrennt. In Klassen/Strukturen etc. stelle ich dann noch einen Unterstrich davor, damit es erstens keine Kollisionen mit Parametern und lokalen Variablen geben kann und zweitens auch mit Autovervollständigung mit Eingeben von nur dem Unterstrich gleich alle Membervariablen kommen.

Konstanten sind bei mir Member eines Konstanten-Typs. Das Token von if z.B. heißt bei mir "Key::If" und ist eine Konstante vom Typ Key.

Würdest du das dann also etwa wie folgt machen?

Code: Alles auswählen

class Key
{
  public:
   static const Key If;
}

Also ich schreibe Konstanten generell groß, egal ob es sich um 'const'-Konstanten, Enums oder sonst irgendwas handelt.

Ich habe durchaus Lösungen für das Problem, indem ich deutlich mehr über Vererbung löse.

Damit wäre ich irgendwie nicht so zufrieden. Was wenn der Fall dann doch einmal eintritt

Manchmal kommt es aber auch vor das ich einenetwas anderen Codingstandard verwende, zum Beispiel wenn ich STL ähnlich Container, Streams oder ähnliche Sachen schreibe. Dann gehe ich meistens in Header von Boost oder der Standardbibliothek und versuche es ähnlich hin zu bekommen...