[Dune] Coding Style

Oliver Sander sander at math.fu-berlin.de
Tue Nov 18 11:38:49 CET 2003


Liebe Mitentwickler!

Bei meinen ersten Ausflügen in den Dune-Code habe ich mich
gefragt, ob dem ganzen ein Coding Style zugrunde liegt, und
wenn ja welcher.  Thimo meinte dann, daß das bisher an
allgemeiner Trägheit gescheitert ist.  Also nehme ich es jetzt in die
Hand.
Das ganze wirkt vielleicht teilweise wie Haarspalterei, aber wir
hoffen doch alle, daß wir bald hundert Spitzenwissenschaftler
als Mitentwickler haben ;-) und dann wird sowas wichtig.

Ich habe mal eine Liste von Punkten erstellt, die mir wichtig
erscheinen.  Ich bitte alle, die das hier lesen, zu möglichst
vielen davon Stellung zu nehmen, und/oder weitere Punkte
zur Diskussion zu stellen.  Dinge, über die Einigkeit herrscht
werde ich dann hübsch aufschreiben und ins Netz stellen.

- Namensgebung
  - Variablen
    Olis Vorschlag: nur Buchstaben und Zahlen, erster Buchstabe
         klein, dann der erste Buchstabe eines neuen Wortes groß.
         z.B. elementCounter
  - Typen
    OV:  Wie Variablen, aber mit einem Großbuchstaben am Anfang
  - Makros (seufz)
    OV: So sie denn sein müssen:  Alles groß
  - Dateien
    OV: Nur Buchstaben, alle kleingeschrieben.  Header mit .hh,
        Implementierungen mit .cc
  - Templateparameter
    OV: Wie Makros
  - #define __HEADER_HH__ (ihr wisst schon)
    Namensregeln für diese defines?

- Einrückungen etc.
  OV: Vier Leerzeichen pro Stufe.  Nach einem 'for', 'if' o.ä.
      kommt die geschweifte Klammer auf die gleiche Zeile.
      Kommt nach dem 'for' nur ein Befehl, so kommt er *nicht*
      auf die gleiche Zeile.

- Exceptions:
  OV: Ja, bitte!

- Doxygen
  OV: Man sollte *alles* dokumentieren!  Insbesondere die
      Parameter (mit @param), denn Rückgabewert, Exceptions
      und (wichtig) die Templateparameter.
      Weiterhin schlage ich folgende Regel vor:  Natürlich
      schreibt man dauernd irgendwelchen Krams und hat dann
      keine Zeit/Lust das ganze sinnvoll zu dokumentieren.
      In diesem Fall sollte man (unbedingt) das betreffende
      Objekt mit einem /** \todo Please doc me! */ versehen.
      So ist wenigstens die Abwesenheit von Dokumentation
      zentral dokumentiert.

- Benutzung von 'assert'
  OV: Spricht da  was dagegen?

- enum vs. static const
  Im moment werden viele Konstanten in Templateklassen mit
  enum {CONSTANT=Value}; definiert.  Ich persönlich finde
  eigentlich static const int CONSTANT = value; etwas
  lesbarer.  Was meint ihr?

- Bildschirmausgabe
  Wie macht man sowas?  Mit printf? Oder mit Streams?  Oder
  will man sich selber was schreiben (wie z.B. UserWriteF
  in UG), das man dann automatisch in ein Logfile umleiten
  kann?

Ich hoffe auf rege Beteiligung,
Viele Grüße,
Oliver

************************************************************************
* Oliver Sander                **                                      *
* Freie Universität Berlin     ** email: sander at math.fu-berlin.de      *
* Institut für Mathematik II   ** phone: + 49 (30) 838 75217           *
* Arnimallee 2-6               ** fax  : + 49 (30) 838 54977           *
* 14195 Berlin, Germany        ** URL  : www.math.fu-berlin.de/~sander *
************************************************************************




More information about the Dune mailing list