Code Styleguide



  • Ich bin einverstanden mit

    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.

    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.



  • 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



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


  • Mod

    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? 😕

    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.



  • 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. 🙂


  • Mod

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



  • 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. 🙂


  • Mod

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



  • 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()



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


  • Mod

    Doppelte sind namespacetrenner?

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

    Geht auch ohne Großbuchstaben

    Wie würdest Du das genau machen?



  • 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.

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

    //original
    void cdi_pci_alloc_ioports(struct cdi_pci_device *device);
    

    eigentlich?

    Vielleicht nur eine

    //geklärt?
    void cdi_pci_device__alloc_ioports(struct cdi_pci_device *device);
    

    ?



  • 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.



  • +gjm+ schrieb:

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



  • 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? 😕

    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. 🙄 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



  • 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.


  • Mod

    Dafür biete ich mich an.

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



  • +gjm+ schrieb:

    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.


  • Mod

    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):

    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



  • Erhard Henkes schrieb:

    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.


Anmelden zum Antworten