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