4. Code Styleguide

Code Styleguide

  • 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