C:Style
Re: C:Stil
So, ich hab jetzt einmal einen Punkt mit Wächtern eingebaut. Kritik ist wie immer erwünscht
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)
OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at
OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: C:Stil
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.
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.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: C:Stil
Hab noch ein wenig hinzugefügt.
Änderungen erwünscht.
Änderungen erwünscht.
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: C:Stil
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: C:Style
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. ^^
Ansonsten den Link zum Diskussionsfred aktualisiert.
Da sind aber tatsächlich noch viele leere Überschriften. ^^
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: C:Style
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.
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.
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
Re: C:Style
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...cloidnerux hat geschrieben: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.
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 hat geschrieben: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.
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)
OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at
OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: C:Style
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.Was machst du denn wenn auch noch typedefs, Klassen, Strukturen oä. dazu kommen, bzw. wie unterscheidest du Membervariablen von Parametern und lokalen Variablen?
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.
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: C:Style
Das Thema interessiert mich sehr.Kerli hat geschrieben: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?
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;
}
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.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Re: C:Style
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önnenXin hat geschrieben:Das Thema interessiert mich sehr.
Und was ist wenn die Variablen aus mehr als nur einem Wort bestehen?Xin hat geschrieben:Lokale Variablen/globale Funktionen werden klein geschrieben. (int i; initProgramm())
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.Xin hat geschrieben:Typnamen und Typmember werden groß geschrieben. (Typname->TypMember)
Würdest du das dann also etwa wie folgt machen?Xin hat geschrieben: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.
Code: Alles auswählen
class Key
{
public:
static const Key If;
}
Damit wäre ich irgendwie nicht so zufrieden. Was wenn der Fall dann doch einmal eintrittXin hat geschrieben:Ich habe durchaus Lösungen für das Problem, indem ich deutlich mehr über Vererbung löse.
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...
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)
OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at
OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at