C/C++ Forum :: Code Styleguide

Erhard Henkes Mitglied 12: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 13: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 15: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 15: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 15: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 18: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 18: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 18:55:58 18.10.2009 Titel:

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

Erhard Henkes Mitglied 01: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 02: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.

Erhard Henkes Mitglied 02:11:57 19.10.2009 Titel:

Dann müsste man aber auch die Mischung zulassen, eben "systemTimer_setFrequency". Oder sehe ich das verkehrt?

volkard Moderator 02:18:51 19.10.2009 Titel:

Erhard Henkes schrieb:

Dann müsste man aber auch die Mischung zulassen, eben "systemTimer_setFrequency". Oder sehe ich das verkehrt?

Ich dachte nur an die Namensräume, die schon bei den file-Funktionen fopen fclose fprintf benutzt wurden, die würden wir heute wohl file_open file_close file_printf schreiben.
Entsprechend wäre dann die Mischform systemTimer_setFrequency auch notwendig. Wobei man aber auch die Bälle flach halten sollte und nicht mit kernel_tools_time_systemTimer_setFrequency rumtoben.

Erhard Henkes Mitglied 02:21:00 19.10.2009 Titel:

Gibt es hier auch eine sinnvolle Möglichkeit dies einzusetzen, ohne Großbuchstaben zu verwenden? (analog tyndur)

volkard Moderator 02:23:04 19.10.2009 Titel:

Erhard Henkes schrieb:

Gibt es hier auch eine sinnvolle Möglichkeit dies einzusetzen, ohne Großbuchstaben zu verwenden? (analog tyndur)

Doppelte sind namespacetrenner?
system_timer__set_frequency()
[x] nicht extrem hübsch, aber auch genießbar

Unregistrierter 02:27:39 19.10.2009 Titel:

Wenn ich eine Funktion namens "systemTimer_setFrequency" in einer Übersetzungseinheit namens "systemTimer.c" finde, würde es mir als "Namensraum" schon reichen. (Geht auch ohne Großbuchstaben).

Erhard Henkes Mitglied 02:27:44 19.10.2009 Titel:

Zitat:

Doppelte sind namespacetrenner?

Das mit dem doppelten Underscore hatte ich mich nicht getraut vorzuschlagen.

Zitat:

Geht auch ohne Großbuchstaben

Wie würdest Du das genau machen?

volkard Moderator 02:32:27 19.10.2009 Titel:

Erhard Henkes schrieb:

Gibt es hier auch eine sinnvolle Möglichkeit dies einzusetzen, ohne Großbuchstaben zu verwenden? (analog tyndur)

Möglicherweise fehlen bei tyndur einfach ein paar doppelte, und zwar stets zwischen klassenname und methodenname.

C/C++ Code:
//zwei _ von mir zugefügt struct cdi_net_driver {...}; void cdi_net_driver__init(struct cdi_net_driver driver); void* cdi_net_driver__destroy(struct cdi_net_driver *driver);

C/C++ Code:
//zwei _ von mir zugefügt struct cdi_net_driver {...}; void cdi_net_driver__init(struct cdi_net_driver driver); void* cdi_net_driver__destroy(struct cdi_net_driver *driver);

C/C++ Code:
//zwei _ von mir zugefügt struct cdi_net_driver {...}; void cdi_net_driver__init(struct cdi_net_driver driver); void* cdi_net_driver__destroy(struct cdi_net_driver *driver);

aber was ist

C/C++ Code:
//original void cdi_pci_alloc_ioports(struct cdi_pci_device *device);

C/C++ Code:
//original void cdi_pci_alloc_ioports(struct cdi_pci_device *device);

C/C++ Code:
//original void cdi_pci_alloc_ioports(struct cdi_pci_device *device);

eigentlich?

Vielleicht nur eine

C/C++ Code:
//geklärt? void cdi_pci_device__alloc_ioports(struct cdi_pci_device *device);

C/C++ Code:
//geklärt? void cdi_pci_device__alloc_ioports(struct cdi_pci_device *device);

C/C++ Code:
//geklärt? void cdi_pci_device__alloc_ioports(struct cdi_pci_device *device);

?

Unregistrierter 03:00:04 19.10.2009 Titel:

Zitat:

Wie würdest Du das genau machen?

Wenn PrettyOS einen Systemtimer hat, dann ist er in der "systemtimer.c" definiert und das "Präfix" "systemtimer_" darf außerhalb der systemtimer.c nicht für Bezeichner verwendet werden.

mngbd Mitglied 12:27:56 19.10.2009 Titel:

+gjm+ schrieb:

Zitat:

Wie würdest Du das genau machen?

Wenn PrettyOS einen Systemtimer hat, dann ist er in der "systemtimer.c" definiert und das "Präfix" "systemtimer_" darf außerhalb der systemtimer.c nicht für Bezeichner verwendet werden.

Dafür meine Stimme. Nur nicht zu viele Reglen, das alles macht sonst keinen Spaß mehr...

mngbd Mitglied 12:37:36 19.10.2009 Titel:

Erhard schrieb:

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:

Ich hatte die 80 Zeichen bis jetzt immer aus religiösem Glauben eingehalten, Argumente habe ich dazu keine. Und Ärger mit den Einrückungen hatte ich auch schon. :rolleyes:

Deshalb wollte ich einige Zeit lang auf 2 Spaces pro Einrückung umsteigen, aber das hat bis jetzt nicht hingehaut.

Ich kenne leider sonst keine sinnvolle Marke. Letztlich ist das aber gar nicht so wichtig, weil man Sourcecode ja hervorragend automatisch neuformatieren kann. Nur zu lange Stringliterale erfordern dann etwas mehr Aufmerksamkeit.

Das wichtigere Thema ist sicherlich die Namenskonvention. Ich befürchte, daß Volkard unabsichtlich ein wenig von unserem guten alten Sprachenkrieg hier hereintragen könnte.

Können wir uns auf folgenden Grundsatz einigen?
Eine konsistente Namenskonvention einzuhalten ist mehr eine Kunst als etwas, das man mechanisch umsetzen kann.

Nachtrag zu den Zeilenlängen und den Druckern:
Ich habe hier keinen funktionierenden Drucker herumstehen, und am Bildschirm läßt man sich leicht verwirren. Der Gnome-Editor in den Ubuntu-Voreinstellungen druckt bis ca. 100 Zeichen pro Zeile:
http://i37.tinypic.com/dzcz2g.png

mngbd Mitglied 12:39:10 19.10.2009 Titel:

Erhard schrieb:

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

Dafür biete ich mich an. Du müsstest dann nur die Korrektur besorgen.

Erhard Henkes Mitglied 13:32:20 19.10.2009 Titel:

Zitat:

Dafür biete ich mich an.

... für das ins Englische übersetzen?

volkard Moderator 14:16:03 19.10.2009 Titel:

+gjm+ schrieb:

Zitat:

Wie würdest Du das genau machen?

Wenn PrettyOS einen Systemtimer hat, dann ist er in der "systemtimer.c" definiert und das "Präfix" "systemtimer_" darf außerhalb der systemtimer.c nicht für Bezeichner verwendet werden.

Aber woran unterscheide ich namespace-Präfixe wie in systemtimer_time von ganz normalen Worttrennern wie in beep_time? Nur daran, daß es die Datei systemtimer.c gibt? Das könnte unerwünschten Effekten führen, daß man bei einer neuen Systemdatei beep.h viele Umbenennungen machen muß oder gar der Systemdatei nur den zweitbesten Namen gibt, um nicht viel bestehenden Code ändern zu müssen.

Erhard Henkes Mitglied 14:44:48 19.10.2009 Titel:

Hier ein erster Vorschlag für die zu verwendenden Typen für einfache Variablen mit Bitte um Ergänzung (stdint.h sollten wir nicht verwenden, damit wir völlig unabhängig bleiben):

Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	typedef unsigned int size_t; typedef unsigned int uint32_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed int int32_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t;

Code:
1 2 3 4 5 6 7 8 9	typedef unsigned int size_t; typedef unsigned int uint32_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed int int32_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t;

Code:
1 2 3 4 5 6 7 8 9	typedef unsigned int size_t; typedef unsigned int uint32_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed int int32_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t;

Das _t sollten wir wohl anhängen, um C99-konform zu bleiben.
http://www.oreillynet.com/pub/a/network/2003/10/07/michael_barr.html

volkard Moderator 14:47:50 19.10.2009 Titel:

Erhard Henkes schrieb:

Code:
typedef unsigned int uint32_t; typedef unsigned long uint32_t;

Code:
typedef unsigned int uint32_t; typedef unsigned long uint32_t;

Code:
typedef unsigned int uint32_t; typedef unsigned long uint32_t;

Ist der uint32_t unsigned int oder unsigned long?
Ansonsten ist die Liste vollständig, bis Bedarf für uint64_t da ist. ptrdiff_t und sowas verwendet eh keiner.

Unregistrierter 15:23:20 19.10.2009 Titel:

volkard schrieb:

Aber woran unterscheide ich namespace-Präfixe wie in systemtimer_time von ganz normalen Worttrennern wie in beep_time?
Nur daran, daß es die Datei systemtimer.c gibt?

So ist es. Unerwünschte Effekte können dann nur noch das Resultat von reinen Designfragen sein.

Erhard Henkes Mitglied 15:32:21 19.10.2009 Titel:

Zitat:

bis Bedarf für uint64_t da ist

Ist in einem Neuentwurf schon vorhanden. Wie macht man das sauber?
unsigned longlong?

volkard Moderator 15:37:18 19.10.2009 Titel:

Erhard Henkes schrieb:

Zitat:

bis Bedarf für uint64_t da ist

Ist in einem Neuentwurf schon vorhanden. Wie macht man das sauber?
unsigned long long?

klar. und feige sein und mit irgend einem STATIC_ASSERT-Makro die Eigenschaft sizeof(uint64_t)==8 absichern. falls je mal eine maschine/compiler auftaucht, wo long long nicht 64 bit hat, kann man dann das passende #ifdef rausfinden.

mngbd Mitglied 15:48:10 19.10.2009 Titel:

Erhard Henkes schrieb:

Zitat:

Dafür biete ich mich an.

... für das ins Englische übersetzen?

Ja, das hatte ich gemeint. Aber wahrscheinlich ist es doch besser, das Ding so knapp zu halten, dass es sich nicht lohnt, die Arbeit für die Übersetzung zu delegieren.

Übrigens wird auch im ANSI-Forum darüber gesprochen:
http://www.c-plusplus.de/forum/viewtopic-var-t-is-252394.html

Erhard Henkes Mitglied 23:59:04 23.10.2009 Titel:

Übergangsweise habe ich Folgendes in die os.h implementiert, damit beide Versionen noch laufen. Später fliegen die alten Types komplett raus. Ihr könnt also für neuen Code schon die neuen verwenden.

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	/// ////////////////////////////////////// /// //// TODO: ANSI TYPEDEFINITIONS //// /// ////////////////////////////////////// // old #define TRUE 1 #define FALSE 0 typedef unsigned int UINT; typedef unsigned short USHORT; typedef unsigned long ULONG; /// ////////////////////////////////////// // new typedef unsigned int size_t; typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed long long int64_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t; /// //////////////////////////////////////

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	/// ////////////////////////////////////// /// //// TODO: ANSI TYPEDEFINITIONS //// /// ////////////////////////////////////// // old #define TRUE 1 #define FALSE 0 typedef unsigned int UINT; typedef unsigned short USHORT; typedef unsigned long ULONG; /// ////////////////////////////////////// // new typedef unsigned int size_t; typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed long long int64_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t; /// //////////////////////////////////////

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	/// ////////////////////////////////////// /// //// TODO: ANSI TYPEDEFINITIONS //// /// ////////////////////////////////////// // old #define TRUE 1 #define FALSE 0 typedef unsigned int UINT; typedef unsigned short USHORT; typedef unsigned long ULONG; /// ////////////////////////////////////// // new typedef unsigned int size_t; typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed long long int64_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t; /// //////////////////////////////////////

Version http://www.henkessoft.de/OS_Dev/Downloads/109.zip (Oct 24, 2009)
beinhaltet bereits die umgestellten typedefs.

Erhard Henkes Mitglied 16:17:49 30.10.2009 Titel:

Wie machen wir das mit TRUE und FALSE? Das habe ich noch nicht ganz verstanden. Nehmen wir da "0" (FALSE) und "ungleich 0" (TRUE) anstelle FALSE und TRUE?

so sieht's bei windef.h aus:

Code:
#ifndef FALSE #define FALSE 0 #endif #ifndef TRUE #define TRUE 1 #endif

Code:
#ifndef FALSE #define FALSE 0 #endif #ifndef TRUE #define TRUE 1 #endif

Code:
#ifndef FALSE #define FALSE 0 #endif #ifndef TRUE #define TRUE 1 #endif

general bacardi Mitglied 16:54:28 30.10.2009 Titel:

typedef enum {false, true} bool;
...
bool b = true;

Badestrand Mitglied 19:28:46 30.10.2009 Titel:

general bacardi schrieb:

typedef enum {false, true} bool;
...
bool b = true;

Erhard Henkes Mitglied 19:44:25 30.10.2009 Titel:

Ja, dann werden wir das implementieren und TRUE und FALSE gegen true und false austauschen. Macht auch Sinn in Richtung C++. C99 hat noch kein bool und true und false?

abc.w Mitglied 20:02:18 30.10.2009 Titel:

Wozu überhaupt ein boolean, es gibt 0 und ungleich 0 und so schreibt man es am Besten explizit hin... :confused:

general bacardi Mitglied 20:51:49 30.10.2009 Titel:

Erhard Henkes schrieb:

C99 hat noch kein bool und true und false?

Doch: http://en.wikipedia.org/wiki/Stdbool.h :cool:

abc.w schrieb:

Wozu überhaupt ein boolean, es gibt 0 und ungleich 0 und so schreibt man es am Besten explizit hin...

Die Intention wird dadurch deutlich, dass es sich um Wahrheitswerte handelt.

abc.w Mitglied 21:00:34 30.10.2009 Titel:

general bacardi schrieb:

abc.w schrieb:

Wozu überhaupt ein boolean, es gibt 0 und ungleich 0 und so schreibt man es am Besten explizit hin...

Die Intention wird dadurch deutlich, dass es sich um Wahrheitswerte handelt.

Informatikermärchen

Erhard Henkes Mitglied 21:13:38 30.10.2009 Titel:

Also, wenn ich in ckernel.c

C/C++ Code:
while(TRUE){/ /}

C/C++ Code:
while(TRUE){/ /}

C/C++ Code:
while(TRUE){/ /}

gegen

C/C++ Code:
while(true){/ /}

C/C++ Code:
while(true){/ /}

C/C++ Code:
while(true){/ /}

austausche, erhalte ich folgende Fehlermeldung:

Zitat:

ckernel.c:332: error: 'true' undeclared

Füge ich

C/C++ Code:
typedef enum {false, true} bool;

C/C++ Code:
typedef enum {false, true} bool;

C/C++ Code:
typedef enum {false, true} bool;

in os.h ein, so läuft das brav durch. Damit können wir "true" und "false" (analog C99 bzw. C++) verwenden. Das ist modern. Daher plädiere ich dafür. Jeder weiß, dass false 0 und true 1 bedeutet.

Bezüglich: "ungleich 0"
Wo finde ich dies in einer Definition? TRUE oder true ist doch in der Regel gleich "1" definiert?

C/C++ Code:
while(1){/ /}

C/C++ Code:
while(1){/ /}

C/C++ Code:
while(1){/ /}

wirkt halt irgendwie seltsam.

volkard Moderator 21:16:44 30.10.2009 Titel:

Erhard Henkes schrieb:

Wo finde ich dies in einer Definition? TRUE oder true ist doch in der Regel gleich "1" definiert?

Ich meine mich zu erinnern, daß true als !false definiert ist. Ob das true==1 wird, ist egal.

general bacardi Mitglied 21:19:27 30.10.2009 Titel:

Erhard Henkes schrieb:

Bezüglich: "ungleich 0"
Wo finde ich dies in einer Definition?

Das steht sicherlich im C-Standard

C/C++ Code:
if (a) / Wenn a ungleich 0 wird verzweigt / { ... }

C/C++ Code:
if (a) / Wenn a ungleich 0 wird verzweigt / { ... }

C/C++ Code:
if (a) / Wenn a ungleich 0 wird verzweigt / { ... }

Zitat:

TRUE oder true ist doch in der Regel gleich "1" definiert?

Nein, true ist das Gegenteil von false. Es gibt nur die beiden. 1 ist eine Zahl und Zahlen gibt es sehr viele. :o)

Erhard Henkes Mitglied 21:22:11 30.10.2009 Titel:

Man findet bei der Suche nach stdbool.h:

http://www.koders.com/c/fidDF4818DD265741F8A74455FC281F0C1CBA35EB47.aspx

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	#ifndef _STDBOOL_H #define _STDBOOL_H /* believe it or not but the Single Unix Specification actually * specifies this header, see * http://www.opengroup.org/onlinepubs/007904975/basedefs/stdbool.h.html / #define bool* _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1 #endif

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	#ifndef _STDBOOL_H #define _STDBOOL_H /* believe it or not but the Single Unix Specification actually * specifies this header, see * http://www.opengroup.org/onlinepubs/007904975/basedefs/stdbool.h.html / #define bool* _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1 #endif

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	#ifndef _STDBOOL_H #define _STDBOOL_H /* believe it or not but the Single Unix Specification actually * specifies this header, see * http://www.opengroup.org/onlinepubs/007904975/basedefs/stdbool.h.html / #define bool* _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1 #endif

http://gel.sourceforge.net/examples/stdbool_8h-source.php

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	00029 #ifndef _STDBOOL_H_ 00030 #define _STDBOOL_H_ 00031 00032 #define __bool_true_false_are_defined 1 00033 00034 #ifndef __cplusplus 00035 00036 #define false 0 00037 #define true 1 00038 00039 #define bool _Bool 00040 #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 00041 typedef int _Bool; 00042 #endif 00043 00044 #endif / !__cplusplus / 00045 00046 #endif / !_STDBOOL_H_ /

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	00029 #ifndef _STDBOOL_H_ 00030 #define _STDBOOL_H_ 00031 00032 #define __bool_true_false_are_defined 1 00033 00034 #ifndef __cplusplus 00035 00036 #define false 0 00037 #define true 1 00038 00039 #define bool _Bool 00040 #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 00041 typedef int _Bool; 00042 #endif 00043 00044 #endif / !__cplusplus / 00045 00046 #endif / !_STDBOOL_H_ /

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	00029 #ifndef _STDBOOL_H_ 00030 #define _STDBOOL_H_ 00031 00032 #define __bool_true_false_are_defined 1 00033 00034 #ifndef __cplusplus 00035 00036 #define false 0 00037 #define true 1 00038 00039 #define bool _Bool 00040 #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 00041 typedef int _Bool; 00042 #endif 00043 00044 #endif / !__cplusplus / 00045 00046 #endif / !_STDBOOL_H_ /

abc.w Mitglied 21:26:36 30.10.2009 Titel:

Erhard Henkes schrieb:

C/C++ Code:
while(1){/ /}

C/C++ Code:
while(1){/ /}

C/C++ Code:
while(1){/ /}

wirkt halt irgendwie seltsam.

Ja, aber nur, weil while kein Funktionsaufruf ist, deshalb gehört ein Leerzeichen zwischen while und (1):

C/C++ Code:
while (1) { / Do nothing, infinite loop / }

C/C++ Code:
while (1) { / Do nothing, infinite loop / }

C/C++ Code:
while (1) { / Do nothing, infinite loop / }

general bacardi Mitglied 21:30:28 30.10.2009 Titel:

abc.w schrieb:

Erhard Henkes schrieb:

C/C++ Code:
while(1){/ /}

C/C++ Code:
while(1){/ /}

C/C++ Code:
while(1){/ /}

wirkt halt irgendwie seltsam.

Ja, aber nur, weil while kein Funktionsaufruf ist, deshalb gehört ein Leerzeichen zwischen while und (1):

C/C++ Code:
while (1) { / Do nothing, infinite loop / }

C/C++ Code:
while (1) { / Do nothing, infinite loop / }

C/C++ Code:
while (1) { / Do nothing, infinite loop / }

while(1) ist sowieso schlecher Stil. Manche Compiler beschweren sich darüber mit "Condition always true". Besser: for(;;)

abc.w Mitglied 21:39:44 30.10.2009 Titel:

general bacardi schrieb:

while(1) ist sowieso schlecher Stil. Manche Compiler beschweren sich darüber mit "Condition always true". Besser: for(;;)

Stimmt. Der gcc sagt hier aber nichts, man muss es wahrscheinlich explizit einschalten. Der Sun Compiler hat da gleich eine andere Warnung ausgegeben, siehe http://www.c-plusplus.de/forum/viewtopic-var-t-is-252358.html (PrettyOS 107er Version)

Zitat:

cc -O -m32 -xc99 -Bstatic -Iinclude -c -o ckernel.o ckernel.c
"ckernel.c", line 209: warning: statement not reached

Erhard Henkes Mitglied 22:29:01 30.10.2009 Titel:

Zitat:

Besser: for( ;; )

"Das ist Geschmacksache", sagte der Affe, als er in die Seife biss.

Das Thema ist allerdings TRUE, true, 1 oder nicht 0.

general bacardi Mitglied 22:35:36 30.10.2009 Titel:

Erhard Henkes schrieb:

Das Thema ist allerdings TRUE, true, 1 oder nicht 0.

Verabschiede Dich von TRUE. Nur Makros schreibt man gross. Enums normalerweise nicht.

Erhard Henkes Mitglied 22:41:24 30.10.2009 Titel:

Bin gerade dabei ...

Das Thema ist true, 1 oder nicht 0.

general bacardi Mitglied 00:49:58 31.10.2009 Titel:

Erhard Henkes schrieb:

Bin gerade dabei ...
Das Thema ist true, 1 oder nicht 0.

Wenn Du C-kompatibel sein willst, nimm 0 für false und alles andere für true. Ansonsten ist es egal. Du kannst es definieren, wie Du möchtest.

abc.w Mitglied 23:49:59 31.10.2009 Titel:

general bacardi schrieb:

typedef enum {false, true} bool;
...
bool b = true;

Übrigens, bei solchen Sachen ist sizeof(bool) == sizeof(int)?

Erhard Henkes Mitglied 13:32:03 01.11.2009 Titel:

Ich denke, dass unter Verwendung des bei C99 eingebauten Typs _Bool folgendes in os.h sinnvoll ist:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	typedef unsigned int size_t; typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed long long int64_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t; #define bool _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	typedef unsigned int size_t; typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed long long int64_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t; #define bool _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	typedef unsigned int size_t; typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned short uint16_t; typedef unsigned char uint8_t; typedef signed long long int64_t; typedef signed long int32_t; typedef signed short int16_t; typedef signed char int8_t; #define bool _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1

Am Unklarsten ist mir die Rolle von "char" bezüglich int8_t bzw. uint8_t.

volkard Moderator 14:06:53 01.11.2009 Titel:

Erhard Henkes schrieb:

Am Unklarsten ist mir die Rolle von "char" bezüglich int8_t bzw. uint8_t.

char dürfte ein eigener typ sein, wobei das aber nicht beobachtet werden kann. er verhält sich genau wie int8_t oder wie uint8_t, je nach maschine. das verhalten kann mit compilerschalter -funsigned-char oder -fsigned-char überschrieben werden.

Erhard Henkes Mitglied 14:18:31 01.11.2009 Titel:

Zitat:

compilerschalter -funsigned-char oder -fsigned-char

Danke für den Tipp! Ich habe mich innerlich nämlich auf -fsigned-char eingerichtet. Hoffe, das ist ok. das hier hatte mich etwas irritiert, als ich den Cast (int8_t*) einbauen musste:

C/C++ Code:
int8_t* exception_messages[] = { (int8_t)"Division By Zero", (int8_t)"Debug", ...

C/C++ Code:
int8_t* exception_messages[] = { (int8_t)"Division By Zero", (int8_t)"Debug", ...

C/C++ Code:
int8_t* exception_messages[] = { (int8_t)"Division By Zero", (int8_t)"Debug", ...

Ist das überflüssig, wenn man -fsigned-char verwendet?

Ich habe ja typedef signed char int8_t; in os.h

volkard Moderator 14:25:45 01.11.2009 Titel:

C/C++ Code:
char* exception_messages[] = { "Division By Zero", "Debug", ...

C/C++ Code:
char* exception_messages[] = { "Division By Zero", "Debug", ...

C/C++ Code:
char* exception_messages[] = { "Division By Zero", "Debug", ...

?
Also char für Texte und (u)int8_t nur, wenn das Ding als Zahl betrachtet wird.

Erhard Henkes Mitglied 19:13:58 02.11.2009 Titel:

@Volkard: Ja, das ist zwar nicht wirklich logisch, erscheint aber praktisch vernünftig. Ich werde das wieder umstellen, damit wir möglichst portabel bleiben.

Zitat:

Also char für Texte und (u)int8_t nur, wenn das Ding als Zahl betrachtet wird.

char wird für Texte (Strings) ab Rev. 18 (SVN) wieder Stück für Stück eingebaut.

Erhard Henkes Mitglied 21:11:36 02.11.2009 Titel:

Ich habe einen ersten Entwurf unseres Styleguide als Diskussionsbasis erstellt:
http://www.henkessoft.de/OS_Dev/Downloads/PrettyOS_Styleguide_C.zip

Erhard Henkes Mitglied 10:39:51 28.02.2010 Titel:

Aus dem IRC: <MrX> Ich schlage die Einführung eines Punktes bezüglich Deklaration im Schleifenkopf vor.

Wir sind gerade dabei, alle for(...) auf c99 umzustellen, mit Deklaration und Scope der Laufvariablen nur innerhalb der Schleife.

abc.w Mitglied 12:13:35 28.02.2010 Titel:

Erhard Henkes schrieb:

Wir sind gerade dabei, alle for(...) auf c99 umzustellen, mit Deklaration und Scope der Laufvariablen nur innerhalb der Schleife.

Das ist alles ok, solange die Schleifenvariable nicht außerhalb des Schleifenkörpers benutzt wird oder irgendeine andere "überschattet" (hier kann man sich mit dem -Wshadow absichern)

Und "for(...)" ist kein Funktionsaufruf und da gehört ein Leerzeichen hin "for (...)"

Auch bei Ausdrücken: Nicht "for(i=0;i<max;++i)", sondern "for (i = 0; i < max; ++i)"

"Coding Style"... ein heikles Thema

Mr X Mitglied 12:30:43 28.02.2010 Titel:

Ich bin gegen ein Leerzeichen hinter for. Ich bin für diese Schreibweise:
for(int i = 0; i < x; ++i)
Wshadow wäre aber in der Tat nützlich. Das sollten wir einführen.

abc.w Mitglied 14:51:45 28.02.2010 Titel:

Mr X schrieb:

Ich bin gegen ein Leerzeichen hinter for. Ich bin für diese Schreibweise:
for(int i = 0; i < x; ++i)

Musst aber zugeben, dass for kein Funktionsaufruf ist(nein,Quatsch,ist nut ein Scherz;))

Nach Möglichkeit auch kein int(sonst sollte x auch ein int sein).

Mr X Mitglied 15:10:19 28.02.2010 Titel:

warum kein "int"? Was meinst Du damit?

Das x und i den gleichen Typ haben sollen?

abc.w Mitglied 19:46:40 28.02.2010 Titel:

Mr X schrieb:

warum kein "int"? Was meinst Du damit?

Das x und i den gleichen Typ haben sollen?

size_t sollte normalerwise verwendet werden. x und i sollten den gleichen Typ vom Vorzeichen her haben. Entweder beide vorzeichenbehaftet oder beide ohne Vorzeichen.

Mr X Mitglied 19:59:25 28.02.2010 Titel:

Das hängt 1. Davon ab, was man grad hochzählt und 2. ist das wichtigste ja wohl, das x und i den gleichen Typ, egal erstmal welchen, haben.

abc.w Mitglied 21:12:06 25.03.2010 Titel:

Mr X schrieb:

Das hängt 1. Davon ab, was man grad hochzählt und 2. ist das wichtigste ja wohl, das x und i den gleichen Typ, egal erstmal welchen, haben.

Nach dem Tipp von Tobiking2 hier http://www.c-plusplus.de/forum/viewtopic-var-t-is-263735.html bezüglich "Optimization Reference Manual" von Intel, Kapitel "3.4.2.2 Optimizing for Macro-fusion", ist es wohl so, dass "unsigned" Datentypen "Macro-fusion", was immer man darunter versteht, ermöglichen. Es gibt in dem Kapitel auch ein Beispiel mit einer for-Schleife. Lesenswert.

Mr X Mitglied 18:25:51 28.03.2010 Titel:

Danke für das Programm, Cuervo

Nunja, jedes mal prüfen zu lassen halte ich für etwas übertrieben, aber ab wär das auf jeden Fall gut.

Erhard Henkes Mitglied 19:48:03 28.03.2010 Titel:

PrettyClean ist eine hübsche, objektive und unbestechliche Monitoring Methodik. Der Schrecken jedes Pretty Code Proggers.

abc.w Mitglied 22:38:11 31.03.2010 Titel:

Erhard Henkes schrieb:

PrettyClean ist eine hübsche, objektive und unbestechliche Monitoring Methodik.

Was macht denn die exe? Habe keine Lust, einem Link zu folgen, der vom gehackten c-plusplus Server angezeigt wird...

Objektiv wäre dieses Tool hier: http://www.splint.org/ Aber das würde die Entwicklung von PrettyOS wahrscheinlich um mehrere Monate verzögern

Mr X Mitglied 00:47:50 30.07.2010 Titel:

So, der Thread wird auch mal einem "Ergebnis" zugeführt. Ich habe dabei im wesentlichen die gängige Praxis in PrettyOS wiedergegeben, die sich ja weitestgehend auch aus dem Meinungen hier entwickelt hat. So haben wir das alles mal zusammengefasst, was vor allem für neue Entwickler hilfreich ist. Das hier ist ein Entwurf, der wird noch ergänzt und erweitert.

Codestyle:

Sprachstandard: Der Sourcecode von PrettyOS soll C99-konform sein
Sprache: Kommentare und Funktionsnamen sollen auf Englisch geschrieben werden
Einrückungen: 4 Leerzeichen, keine Tabs
Maximale Zeilenlänge: Keine, es wird gebeten, die Zeilen aber nicht übertrieben lang werden zu lassen.
Zeilenenden: Wir verwenden zwecks Lesbarkeit unter manchen Texteditoren die unter Windows üblichen Zeilenenden: CR LF

Blöcke:
Blockanfang und Blockende nehmen jeweils immer eine separate Zeile in Anspruch (-> { und } in separate Zeile)
Bei Funktionsaufrufen wird zwischen Namen der Funktion und der Parameterliste kein Leerzeichen eingefügt

C/C++ Code:
void foo() { // blabla }

C/C++ Code:
void foo() { // blabla }

C/C++ Code:
void foo() { // blabla }

Kommentare:
Kommentare sind bei einzeiligen Kommentaren mit "//" einzuleiten. Kommentare im Doxygen-Style sollten zwecks Lesbarkeit vermieden werden.

Benennungsregeln:
Als Namespace-Ersatz nutzen wir Unterstriche, ansonsten wird lowerCamelCase verwendet:

C/C++ Code:
void timer_getCurrentSeconds();

C/C++ Code:
void timer_getCurrentSeconds();

C/C++ Code:
void timer_getCurrentSeconds();

Wir verwenden keine ungarische Notation.

Variablendeklaration:
Variablen sind dort zu deklarieren/definieren/initalisieren, wo sie nötig sind. Das bedeutet, den Scope möglichst gering halten.
Pointer:

C/C++ Code:
int x; int* i = &x; *x = 4;

C/C++ Code:
int x; int* i = &x; *x = 4;

C/C++ Code:
int x; int* i = &x; *x = 4;

Header und Sourcefiles:
Jedes Sourcefile soll die Lizenzbedingungen enthalten. Die Lizenz ist, wie in z.B. ckernel.c, unten einzufügen, ein Hinweis auf die Lizenz oben. Bitte einfach aus bestehenden Sourcedateien nachmachen.
In Headern Includeguards nicht vergessen.

NULL oder 0 bei Pointern
Wir bevorzugen direkt die 0, daher wurde die NULL im Kernel gestrichen. Pointer sind also mit 0 anstatt NULL als Nullpointer zu markieren

Commit-Regeln:
Bitte beim Committen folgende Vorgehensweise beachten:
1) Update
2) Code schreiben

2.1) Styleguide beachten
3) in ckernel.c Version und Revision aktualisieren. Die Revisionsnummer ist immer zu erhöhen. Bei der Versionsnummer die letzte Stelle erhöhen, falls es funktionale Änderungen am Kernel gab.
4) Rebuild von PrettyOS und Testen des Floppyimages um sicherzustellen, dass noch alles funktioniert
5) "Release Notes" schreiben. Diese sowohl im Thread "Sourcecode Fortschritt" als auch beim Commit selbst angeben.
6) Nochmal updaten, ggf. vorherige Schritte wiederholen
7) Committen
8) Neue Version im IRC bekannt machen(, wenn Entwickler da sind.)

Wenn es den Wunsch gibt, dass die anderen an bestimmten Sourcecodebereichen temporär nichts ändern sollen, dann äußert den bitte im Forum.

Mr X Mitglied 13:27:09 24.06.2011 Titel:

Farbstil
Um einen einheitlichen, übersichtlichen Farbstil zu schaffen und die Lesbarkeit der Ausgabe zu erhöhen, sollen folgende farbliche Kennzeichnungen genutzt werden. Um diese global umstellen zu können, ist das angegebene Alias zu verwenden. Die Verwendung anderer Farben ist, wo es sinnvoll ist, allerdings nicht verboten.

Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	Meldungstyp Alias Aktuelle Farbzuweisung ------------------------------------------------------------ Fehler ERROR LIGHT_RED Erfolg SUCCESS GREEN Überschriften HEADLINE CYAN Tabellenüberschriften TABLE_HEADING LIGHT_GRAY Daten DATA BROWN Wichtige Daten IMPORTANT YELLOW Normaler Text TEXT WHITE

Code:
1 2 3 4 5 6 7 8 9	Meldungstyp Alias Aktuelle Farbzuweisung ------------------------------------------------------------ Fehler ERROR LIGHT_RED Erfolg SUCCESS GREEN Überschriften HEADLINE CYAN Tabellenüberschriften TABLE_HEADING LIGHT_GRAY Daten DATA BROWN Wichtige Daten IMPORTANT YELLOW Normaler Text TEXT WHITE

Code:
1 2 3 4 5 6 7 8 9	Meldungstyp Alias Aktuelle Farbzuweisung ------------------------------------------------------------ Fehler ERROR LIGHT_RED Erfolg SUCCESS GREEN Überschriften HEADLINE CYAN Tabellenüberschriften TABLE_HEADING LIGHT_GRAY Daten DATA BROWN Wichtige Daten IMPORTANT YELLOW Normaler Text TEXT WHITE