Start Info Community Spielen
 
 

Morgengrauner Dokumentation

Dateipfad: /home/mud/mudlib/doc//wiz/mudlib-codestyle

Wollt ihr Code in der allgemeinen, oeffentlichen Mudlib anschliessen, bitte
beachtet die folgenden Hinweise zum Codestyle (nicht erschoepfend):

* Einrueckungen per Leerzeichen, nicht Tabs
* Einrueckung von 2 oder 4 Leerzeichen pro Ebene
* praegnante und viele Kommentare
* Kommentare sollen nicht (nur) beschreiben, was der Code tut, sondern
  vor allem, was er tun soll und warum.
* keine lambdas
* Bei inline-closures die function-Syntax statt der (: :)-Syntax verwenden.
* else, else if in eine eigene Zeile
* { am Beginn von Bloecken soll in eine eigene Zeile.
* Nach ifs, Loops & Co: umfasst der davon kontrollierte Code mehr als eine
  physische Zeile Code, einen Block mit { } formulieren.
* keine return fun(), 0;
* Folgende #pragmas sind zwingend:
  rtt_checks (impliziert save_types)
  strong_types (strict_types in neuem Code empfohlen)
  warn_deprecated, warn_empty_casts, warn_missing_return, warn_dead_code,
  warn_function_inconsistent, warn_applied_functions, range_check,
  warn_unused_variables, warn_unused_values
* Pfade, die absolut sind, sollen auch mit / beginnen, z.B. 
  inherit "/std/thing", nicht inherit "std/thing"
* Der Code darf *keine* Warnungen des Compilers oder Laufzeitwarnungen
  ausloesen!

Commits und Patches
* Bei Patches bitte keine inhaltlichen Aenderungen mit jeder Menge
  Whitespace-Aenderungen vermischen.
* Pro Patch bitte nur eine inhaltliche Aenderungen einschliessen
* Jeder Commit muss eine aussagekraeftige Commitmeldung haben und
  folgendem Style entsprechen:
  * Die erste Zeile ist der Betreff
    Dieser beschreibt in max. 50-60 Zeichen, worum es geht
  * Eine leere Zeile
  * Beliebig viele Zeilen mit Beschreibung von max. 70 Zeichen Laenge
    Dieser Text sollte die Aenderung erklaeren und auch das "Warum und
    Wieso" der Aenderung erlaeutern.
* Commits sollten sich sauber auf die aktuelle Spitze vom master-Zweig
  anwenden lassen. (Bzw. zumindest nicht schon Wochen alt sein.)

Benennung von Properties:
* der interne Name von Properties in der Basis-Mudlib beginnt immer mit
  "p_lib_". Niemand sonst sollte Properties mit diesem Praefix erstellen.

Sonstiges:
* In der Mudlib wird keine neue Funktion(alitaet) angeschlossen, bevor die
  Dokumentation dafuer fertig ist.
  Am liebsten ist mir, bei der Konzeptentwicklung zuerst die fertige
  Dokumentation (Manpage) fuer Nutzer/Spieler zu entwickeln, bevor ein Magier
  ueberhaupt eine Zeile Code schreibt.
* Patches muessen eine Zusammenfassung haben, welche kurz erlaeutert,
  was dieser Patch fixen/aendern/verbessern soll und auf welche Weise
  diese umgesetzt wird. (Anders gesagt: eine Commit-Message)
* Bei Aenderungen von Manpages bitte nur bei inhaltlichen Aenderungen den
  Abschnitt "Letzte (inhaltliche) Aenderung" aktualisieren.

LETZTE INHALTLICHE AeNDERUNG:
  22.1.2022, Zesstra


zurück zur Übersicht

YOUTUBE | FACEBOOK | TWITTER | FEEDBACK | IMPRESSUM | DATENSCHUTZ 1992–2022 © MorgenGrauen.