C/C++ Forum :: Code Styleguide

Erhard Henkes Mitglied 11:22:52 18.10.2009 Titel:

Ich denke wir sollten rasch einen style guide für PrettyOS schaffen. Hier der Link zu dem von Tyndur, den wir als Basis für unsere Diskussion verwenden können:
http://git.tyndur.org/?p=tyndur.git;a=blob;f=doc/c ....... h=da5c05be62085bd6addd3dafc094029fd293fe64;hb=HEAD

Themen:
Einrueckung
Maximale Zeilenlaenge
Platzierung der geschweiften Klammern
Platzierung von Leerzeichen
Benennung
Kommentare

Ich bin übrigens dafür, alle Kommentare, Funktions-, Variablennamen in Englisch zu wählen/schreiben.

Wir müssen hierüber entscheiden:

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Ich tendiere zu Letzterem, auch wenn eine Zeile verloren geht, weil ich die Klammern auf einer Spalte übereinander sehen möchte. Bei tyndur geht dies trotz Regel kreuz und quer.

Bei Zeigern bevorzuge ich - analog tyndur - char* p anstelle char * p oder char *p, weil mich Letzteres zu sehr an den Dereferenzierungs-Operator (Inhalt von ...) erinnert.
Ich schreibe auch schon immer for(...) anstelle for (...), aber das sind Kleinigkeiten, bei denen man sich umgewöhnen kann.

Ich würde auch vorschlagen, den Styleguide in Englisch zu verfassen.
Wie wird das allgemein gesehen?

Tobiking2 Mitglied 12:26:17 18.10.2009 Titel:

Den Codestil von tyndur find ich soweit ganz gut. Ich verwende zwar selber lieber CamelCase, aber in C machen die Unterstriche schon Sinn, wenn man eine Variable mit einem Prefix für den jeweiligen Bereich versieht.

Badestrand Mitglied 14:11:27 18.10.2009 Titel:

Ich bin auch dafür, den Sourcecode plus Kommentare komplett in Englisch zu verfassen.
Bei den Konventionen der Kommentare würde ich eher mehr Freiheiten lassen. Im Tyndur-Sourcecode hat das mit den Doxygen-Kommentaren auch nicht so wirklich geklappt, teils fehlend, teils falsch/veraltet. Die geöffnete geschweifte Klammer gehört m.E. immer in die nächste Zeile, so viel Platz ist dann doch noch. Einrückung ist ein heißes Thema. Leerzeichen und Zeilenlänge sollten meiner Meinung jedem selbst überlassen sein.

Ich fände es schade, auf Großbuchstaben zu verzichten, ich mag PascalCase für Typen, ist in C aber ja leider nicht gängig.

Erhard Henkes Mitglied 14:23:17 18.10.2009 Titel:

Zitat:

Ich fände es schade, auf Großbuchstaben zu verzichten, ich mag PascalCase für Typen, ist in C aber ja leider nicht gängig.

Ich habe es bisher nicht ganz einheitlich gehalten, stelle aber fest, dass ich so etwas wie "sleepSeconds" oder "sleepMilliSeconds" aus dem Gedächtnis öfters falsch geschrieben habe. Wenn man konsequent Underscores und Kleinschreibung verwendet ist dies diesbezüglich ein Vorteil. "systemTimer_setFrequency" ist auch nicht optimal zum Einprägen, daher könnte "system_timer_set_frequency" von Vorteil sein.

volkard Moderator 14:36:56 18.10.2009 Titel:

Erhard Henkes schrieb:

Wenn man konsequent Underscores und Kleinschreibung verwendet ist dies diesbezüglich ein Vorteil. "systemTimer_setFrequency" ist auch nicht optimal zum Einprägen, daher könnte "system_timer_set_frequency" von Vorteil sein.

Vielleicht steckt hinter dem underscore da mehr. Ist vielleicht das gemeint, was man in anderer Sprache als systemTimer::setFrequency schreiben würde? Vielleicht kann man mit Unterstrichen sozusagen Namensräume basteln. Dann müßte man einführen, daß underscores in Bezeichnern nur diesen Zweck haben.

mngbd Mitglied 17:51:46 18.10.2009 Titel:

Ich bin einverstanden mit

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Code:
if (file == NULL) { return NULL; }

Aber das ist eine religöse Angelegenheit, in der du (Erhard) notfalls ein Machtwort sprechen musst, wenn es uns die Einheitlichkeit wichtig ist.

Ich mache Einrückungen immer mit Leerzeichen und zwar mit 4 davon.

Zitat:

Ich würde auch vorschlagen, den Styleguide in Englisch zu verfassen.

Mir persönlich ganz egal. Da kommt es wahrscheinlich auf die Zielgruppe an. Wenn wir viele deutschsprachige Jugendliche erreichen wollen, könnte das auch nach hinten los gehen, wenn wir unser Englisch nicht konsequent halbwegs einfach halten. Immerhin kenne ich die Tutorials auf www.henkessoft.de nur deshalb, weil ich damals mit den englischen Tutorials noch überfordert war.

mngbd Mitglied 17:55:04 18.10.2009 Titel:

Zitat:

Vielleicht kann man mit Unterstrichen sozusagen Namensräume basteln. Dann müßte man einführen, daß underscores in Bezeichnern nur diesen Zweck haben.

Das ergibt Sinn. Allerdings müssen wir auch das hier vermeiden:
http://thedailywtf.com/Articles/CodeThatDocumentsItselfSoWellItDoesNotNeedComments.aspx

mngbd Mitglied 17:55:58 18.10.2009 Titel:

Zeilenlänge: ich bin definitiv dafür, die üblichen 80 Zeichen einzuhalten.

Erhard Henkes Mitglied 00:57:27 19.10.2009 Titel:

80 Zeichen hatte ja schon mein Commodore C64 in den 80er Jahren.

Die 80 Zeichen pro Zeile habe ich bisher im Sourcecode überschritten. Durch Einrückungen fangen manche Zeilen ja erst bei 20 an. Daher bin ich für das Zulassen von mehr als 80 Zeichen pro Zeile (incl. Leerzeichen).

Was wäre denn die nächste sinnvolle Marke, die sich an einem Drucker ausrichtet? :confused:

Zitat:

Immerhin kenne ich die Tutorials auf www.henkessoft.de nur deshalb, weil ich damals mit den englischen Tutorials noch überfordert war.

Das ist ein überzeugendes Argument. Da der Styleguide bezüglich des Textes (ohne Beispiele) erwartungsgemäß nicht allzu lang sein wird, kann man ihn vielleicht auch in zwei Sprachen führen, also deutsch und englisch.
Wir könnten den Styleguide zunächst in deutsch entwickeln und verabschieden, dann würde ich ihn anschließend ins Englische übersetzen, um Hürden für vorwiegend englisch-sprachige Mitglieder möglichst niedrig zu halten. Bezüglich englisch würde ich - wegen Gewöhnung - die US-amerikanische Schreibweise wählen.

Unregistrierter 01:07:43 19.10.2009 Titel:

volkard schrieb:

Vielleicht kann man mit Unterstrichen sozusagen Namensräume basteln.

Gute Idee! Dann muß man sich beim Quellcode lesen nicht immer einen Wolf suchen.