Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15
  1. #1
    CIH-Virus Avatar von -[RiDER]-
    Registriert seit
    05.01.2007
    Beiträge
    496

    Standard Coding-Standard

    Der Autor Klaus Schmaranz hat sich die Mühe gemacht, die Semantik der Sprache C zu standardisieren. Ich lege wirklich allen nah, sich an diesen Standard zu halten, da er das Lesen von (fremden bzw. eigenen alten) Source-Codes wirklich erheblich erleichtert! Spätestens, wenn man im Team arbeitet, ist solch ein Standard unumgänglich.
    Zitat Zitat von Klaus Schmaranz in seinem Buch "Softwareentwicklung in C"
    Generelle Regeln
    Die folgenden Prinzipien verbessern die Lesbarkeit und Wartbarkeit eines Programms sehr stark:

    Einfachheit:
    • Das Prinzip der Einfachheit ist auch als das KISS-Prinzip (Keep It Small and Simple) bekannt. Kurz gesagt sollen Funktionen genau eine, für ihren Abstraktionslevel adäquate, atomare Aufgabe erfüllen. Niemals sollen Funktionen mehrere Aufgaben auf einmal erfüllen, genauso wenig, wie sie Aufgaben erfüllen sollen, die in einen anderen Abstraktionslevel gehören (=Durchgriff nach unten oder oben). Die Parameterlisten von Funktionen sollen so kurz und übersichtlich wie möglich gehalten werden. Funktionen selbst sollen als Faustregel niemals mehr als 60 Zeilen lang sein. Eine durchschnittliche Länge von ca. 30 Zeilen ist zu bevorzugen.
    Intuitivität:
    • Das Prinzip der Intuitivität bedeutet, dass man den geschriebenen Source-Code "wie ein Buch" lesen und verstehen können muss, und zwar ohne Kommentare im Source-Code und ohne Erklärungen des Programmierers! Damit ist impliziert, dass Variablen- und Funktionsnamen sprechend sein und genau ihrer Funktionalität entsprechend benannt sein müssen. Einbuchstabenvariablen, wie z.B. i, sind nicht erlaubt. Unnötige Kommentare werden als störend erachtet und sollen dementsprechend weggelassen werden. Ein typisches Beispiel für solche unnötigen Kommentare wäre:
      count++; // and here the counter is incremented
    Einheitlichkeit:
    • Verwandte Teile im Source-Code müssen denselben Prinzipien folgen. Z.B. wenn eine Funktion copy als ersten Parameter die Destination und als zweiten Parameter den Source nimmt, dann müssen verwandte Funktionen, wie z.B. move, sich an dieselben Konventionen halten. Genauso gilt dies z.B. in einer struct für einen Knoten. Wenn für diesen in der Implementation einer einfach verketteten Liste der Pointer auf das nächste Element unter dem Namen next ansprechbar ist, dann darf er nicht in einem Knoten für eine doppelt verkettete Liste auf einmal z.B. successor heißen.
    Zitat Zitat von Klaus Schmaranz in seinem Buch "Softwareentwicklung in C"
    Coding-Rules
    Die hier angeführten Regeln helfen, den Source-Code so weit wie möglich zu vereinheitlichen und damit die Arbeit im Team zu erleichtern:
    • Die Sprache für Source-Code ist Englisch. Dies gilt für alle Teile eines Programms, von Variablennamen über Funktionsnamen bis zu Kommentaren im Source-Code.
    • Der gebrauch von Block-Kommentaren (/* comment */) ist zu vermeiden.
      Stattdessen müssen Zeilenkommentare (// comment) eingesetzt werden.
      Dies macht Source-Code robuster gegen Änderungen und erleichtert
      das Debugging.
    • Wenn es sich nicht vermeiden lässt z.B. algorithmische Details in Form von Kommentaren in den Source-Code einzubringen, dann ist ein Block mit einer vollständigen Erklärung des Algorithmus vor der Implementation des Algorithmus selbst zu schreiben. Es darf die Kommentierung des Algorithmus nicht im laufenden Source-Code Zeile für Zeile erfolgen, denn sonst wird der Code durch die Kommentare unleserlich.
    • Sollten jemals Codezeilen in das Programm Eingang finden, bei denen beim Lesen der Zeile nicht sofort klar ist, was sie tut, dann muss dies in einem kurzen Kommentar dort festgehalten werden. Jedoch sollte man sich immer sehr gut überlegen, ob es nicht eigentlich ein besseres, leichter lesbares Konstrukt gibt, das keinen Kommentar braucht.
    • Globale Variablen sind nach allen Möglichkeiten zu vermeiden.
    • Wenn aus irgendwelchen Gründen böse Hacks im Source-Code nicht vermeidbar sind (z.B. Zeitdruck), so sind diese unbedingt in hack-start und hack-end Kommentare zu fassen, damit man sie einfach wieder finden und ausbessern kann. Die hack-... Kommentare haben die folgende Form:
      Code:
      // FIXXME (<author, date>) -> <description of the hack>
        [..... the code with the hack .....]
      // END FIXXME (<author, date>)
      Hier gehört das Keyword FIXXME immer mit zumindest zwei 'X' geschrieben, denn damit kann man leicht nach ihm suchen. Je nachdem, wie schlimm der Hack ist, können auch mehrere 'X' vorkommen. Als Faustregel für die Abstufung gilt, dass der SVH (=Schlimmste Vorstellbare Hack) mit 5 'X' geschrieben wird.
    • Namen von Bezeichnern müssen den folgenden Konventionen genügen:
      • Funktionen: erstesWortKleinRestCapitalizedOhneUnderlines
      • Konstanten: GROSS_MIT_UNDERLINES
      • Lokale Variablen: klein_mit_underlines
      • Globale Variablen: klein_mit_underlines_und_underline_am_ende_
      • Structures: _CapitalizedMitUnderlinesZuBeginnUndEnde_
        • Diese dürfen nicht direkt verwendet werden, sondern nur über ein typedef (=typedef'ed Structures)!
      • typedef'ed Structures: DurchgehendCapitalizedOhneUnderlines
      • Unions: _CapitalizedMitUnderlinesZuBeginnUndEnde_
        • Diese dürfen nicht direkt verwendet werden, sondern nur über ein typedef (=typedef'ed Unions)!
      • typedef'ed Unions: DurchgehendCapitalizedOhneUnderlines

    • Die Struktur des Source-Codes muss den folgenden Prinzipien genügen:
      • Jedes File muss einen Header besitzen, in dem zumindest der Filename, und eine kurze Beschreibung des Inhalts zu finden sind. In der Praxis hat es sich eingebürgert, dass weiters der Name des Autors, das Erstellungsdatum, das letzte Änderungsdatum, eine Versionsnummer und ein Copyright-Statement im Header stehen.

      • Geschwungene Klammern für Code-Blöcke müssen in einer eigenen Zeile stehen. Die Einrückung der Klammern entspricht genau dem umschließenden Block. Der eingeschlossene Block selbst muss genau um 2 Spaces eingerückt sein. Einrückungen dürfen ausschließlich mit Spaces gemacht werden, Tabs sind verboten, denn sonst kann es mit verschiedenen Editor-Einstellungen und beim Drucken Probleme geben.

      • Vor jeder Funktionsdefinition muss eine Linie der folgenden Form stehen, damit eine Funktion beim Lesen des Source-Codes visuell hervorsticht:
        Code:
        //--------------------------------------------------
        Diese Linie soll in der Regel mit 60-70 '-' geschrieben werden.

      • Zwischen dieser Linie und dem Header der Funktion muss in kurzen Worten beschrieben werden, wozu diese Funktion dient. Bei größeren Projekten muss auch beschrieben sein, was bei den einzelnen Parametern erwartet wird, welche Randbedingungen gelten, welche Return-Values zu erwarten sind und wie diese zu interpretieren sind.
    Das Buch, in dem dieser "Coding-Standard" definiert wird:

    Softwareentwicklung in C (von Klaus Schmaranz, 408 Seiten)
    Verlag: Springer, Berlin; Auflage: 1 (September 2001)
    ISBN-10: 3540419586
    ISBN-13: 9783540419587

    Ich kann das Buch übrigens nur empfehlen! Es eignet sich sowohl für Anfänger, als auch für Fortgeschrittene.

    MfG RiDER

    /*noctem: Ich habe mir erlaubt den Thread Sticky zu machen. */
    Geändert von -[RiDER]- (14.06.2009 um 10:34 Uhr) Grund: Durch neue Board-Software entstandene Formatierungsprobleme behoben

  2. #2
    W32.Klez
    Registriert seit
    23.05.2007
    Beiträge
    401

    Standard

    Hallo -[RiDER]-,
    Habe früher mal nach sowas gesucht. Danke dir fürs reinstellen.
    Werde mich sicher daran halten
    Micah joined #CS
    0meg4: kA mehr wo das war, musst mal gucken
    0meg4: Hi Micah
    Micah: Welche von euch Fotzen möchte mal geleckt werden?!
    Jacks^2: o_O
    Micah: ja komm gibs mir... erzähl was!
    Micah: hab schon die ganze Zeit einen richtig harten
    0meg4: Ich glaub du hast da was verwechselt. Du bist hier im #CS was für "Counter-Strike" steht, nicht für "Cyber-Sex" :-O
    Micah: Verdammt.
    Micah left #CS
    Jacks^2: lol xD
    0meg4: xD

  3. #3
    Der mit Anatidaephobie Avatar von blackberry
    Registriert seit
    11.07.2008
    Beiträge
    2.350

    Standard

    Zum Thema // in C...
    Im ANSI-Standart sind // doch noch nicht als Kommentarbezeichner eingeführt, oder irre ich mich da?

    Test:
    Code:
    #include <stdio.h>
    
    
    int main(void)
    {
    	// comment
    	return 0;
    }
    In der Konsole:
    Code:
    blackberry@system:~/Desktop$ gcc -ansi a.c -o a
    a.c: In function ‘main’:
    a.c:6: error: expected expression before ‘/’ token
    blackberry@system:~/Desktop$ ls
    a.c
    blackberry@system:~/Desktop$ gcc -std=c99 a.c -o a
    blackberry@system:~/Desktop$ ls
    a  a.c

    PDFTT cr3w a.E. — ReiDC0Re, lindor, Sera, berry
    please do feed the trolls crew and elk
    Ehrenwerte Mitglieder im Ruhestand: OpCodez, SFX.
    "Was sich blackberry gerade denkt" — Vorsicht! Frei laufender Wahnsinn!
    Zitat von fuckinghot19: "PS: Blackberry ist auf FH der Trollkönig ^^."
    An dieser Stelle danke ich all meinen Fans und Hatern gleichermaßen ^.^

  4. #4
    CIH-Virus Avatar von -[RiDER]-
    Registriert seit
    05.01.2007
    Beiträge
    496

    Standard

    Hi
    Zitat Zitat von BlackBerry
    Zum Thema // in C...
    Im ANSI-Standart sind // doch noch nicht als Kommentarbezeichner eingeführt, oder irre ich mich da?
    Ja, da hast Du Recht.
    Diese Zeilenkommentare werden auch "C++-Stil-Kommentare" (probier mal -pedantic anstelle von -ansi) genannt, eben weil sie erst mit C99 eingeführt wurden und von C++ abgekuckt wurden.

    In dieser Hinsicht (und eigentlich auch in jeder anderen) ist C99 also C89 vorzuziehen, da sich Zeilenkommentare zum Kommentieren von Kode besser eigenen als Blockkommentare - allein schon aus dem Grund, dass sich Blockkommentare nicht verschachteln lassen und somit das Auskommentieren von kommentiertem Kode unmöglich machen.

    GreetZ RiDER

  5. #5
    DateMake Dialer
    Registriert seit
    10.10.2008
    Beiträge
    99

    Standard

    Cool, viele Sachen dabei die ich noch nicht wusste.
    Mit wievielen Leerzeichen rückt man jetzt Funktions-, Schleifenblöcke etc. ein, auch mit 2?

  6. #6
    CIH-Virus Avatar von -[RiDER]-
    Registriert seit
    05.01.2007
    Beiträge
    496

    Standard

    Hi
    Zitat Zitat von Darkthief
    Mit wievielen Leerzeichen rückt man jetzt Funktions-, Schleifenblöcke etc. ein, auch mit 2?
    Jopp.

    Geschwungene Klammern für Code-Blöcke müssen in einer eigenen Zeile stehen. Die Einrückung der Klammern entspricht genau dem umschließenden Block. Der eingeschlossene Block selbst muss genau um 2 Spaces eingerückt sein. Einrückungen dürfen ausschließlich mit Spaces gemacht werden, Tabs sind verboten, denn sonst kann es mit verschiedenen Editor-Einstellungen und beim Drucken Probleme geben.
    GreetZ RiDER

  7. #7
    Stiller Leser
    Registriert seit
    01.10.2010
    Beiträge
    3

    Standard

    _CapitalizedMitUnderlinesZuBeginnUndEnde_
    Das ist ungünstig. Namen, die mit einem Unterstrich gefolgt von einem Großbuchstaben anfangen, sind reserviert. Siehe z.B. http://publib.boulder.ibm.com/infoce.../ref/ident.htm, Abschnitt "Reserved identifiers".

    Ansonsten finde die Regeln ganz gut, auch wenn mir manches etwas zu restriktiv erscheint (ich bevorzuge z.B. 4 Leerzeichen und mag camelCase nicht).

  8. #8
    CIH-Virus Avatar von -[RiDER]-
    Registriert seit
    05.01.2007
    Beiträge
    496

    Standard

    Zitat Zitat von rand Beitrag anzeigen
    Namen, die mit einem Unterstrich gefolgt von einem Großbuchstaben anfangen, sind reserviert.
    Das ist Quatsch.
    Vllt. machen das manche Compiler, der Standard schreibt es aber definitiv nicht vor!

    Zitat Zitat von rand Beitrag anzeigen
    (ich bevorzuge z.B. 4 Leerzeichen und mag camelCase nicht).
    Mit "4 Leerzeichen" meinst Du sicher die Breite der Einrückung. Ja, da gehen die Geschmäcker auseinander. Hauptsache ist, dass man im Team einheitlichen Einrückstil hat!

    Tabs werden oft bevorzugt, da man im Editor ihre (angezeigte) Breite festlegen kann. Bei makefiles und in Python bleibt einem dabei garkeine Wahl, da muss man Tabs benutzen. C ist das egal, in Team sollte mans halt einheitlich machen (entweder alle Tabs, oder alle 2 Leerzeichen, oder alle 4 Leerzeichen usw.).

    Und CamelCase finde ich auch oft unschön. Hat sich aber erstaunlich stark eingebürgert. Auch hier gilt: Im Team Haupsache einheitlicher Stil, wie der genau aussieht, kann ja vom OP abweichen, ist nur ein Vorschlag aus dem Buch und vieles davon ist nützlich und kann übernommen werden, ohne dass man sich selbst was ausdenken muss.

    GreetZ RiDER

  9. #9
    I'm in ur VM. Avatar von l0dsb
    Registriert seit
    23.07.2007
    Beiträge
    1.038

    Standard

    Rider lebt noch/wieder! :O

    Um OpCodez Argument mal zu vollenden:

    Der Vorteil der geschwungenen Klammer auf derselben Zeile ist, effektiv eine Zeile einzusparen. Man sagt, man hätte so eine bessere Übersicht über den Code, da man mehr Zeilen sieht.

    Ich verwende die Technik nicht, da ich mit dem Platz auf dem Bildschirm klar komme. Spätestens, wenn mir Platz fehlt und Scrollen unnötig langwierig ist, um einen Codeteil zu verstehen, sollte ich ihn sowieso in mehrere kleinere Funktionen/Code-Blöcke auslagern.

    Ganz zu schweigen von der Schwierigkeit, zugehörige Klammern auf einen Blick zu erkennen, wie es bei OpCodez' Methode der Fall wäre. Nun gut, Stilfrage.
    I can haz RCE?

  10. #10
    print&lt;&gt;=~y/0-9//,$/ Avatar von 0x30
    Registriert seit
    01.02.2010
    Beiträge
    468

    Standard

    Ich habe meinen Eigenen Stil und damit kann und lebt mein Team
    Je nach Lust und Laune verwende ich camelCase oder auch nicht. Es kommt auch immer darauf was programmiert wird.
    Bei der Einrückung verwende ich meine schönen VIM definitionen, ist aber je nach Sprache unterschiedlich
    Geändert von 0x30 (18.10.2010 um 15:27 Uhr)
    Code:
    $_=<>;map$-+=$_,/./g;print$-,$/
    +0x60

Seite 1 von 2 12 LetzteLetzte

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •