4. Code Styleguide

Code Styleguide

  • V

    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.

    0
  • E
    Mod

    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:

    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

    0
  • V
     

    char* exception_messages[] =
{
    "Division By Zero",        "Debug",   ...

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

    0
  • E
    Mod

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

    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.

    0
  • E
    Mod

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

    0
  • E
    Mod

    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.

    0
  • A

    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 😉

    0
  • M

    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.

    0
  • A

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

    0
  • M

    warum kein "int"? Was meinst Du damit?

    Das x und i den gleichen Typ haben sollen?

    0
  • A

    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.

    0
  • M

    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.

    0
  • A

    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.net/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.

    0
  • M

    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.

    0
  • E
    Mod

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

    0
  • A

    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 😉

    0
  • M

    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

    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:

    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:

    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.

    0
  • M

    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.

    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
    0
  • E
    Mod

    Frage:
    Wie bringt man VS dazu, 4 Leerzeichen statt Tabs zu setzen?

    Antwort:
    Optionen->Text-Editor->C/C++->Tabstopps.
    Dort dann "Leerzeichen einfügen" wählen.

    0
Anmelden zum Antworten