blob: 77b4baa82320735245d4bba3f2fb932a66703786 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001Wollt ihr Code in der allgemeinen, oeffentlichen Mudlib anschliessen, bitte
2beachtet die folgenden Hinweise zum Codestyle (nicht erschoepfend):
3
4* Einrueckungen per Leerzeichen, nicht Tabs
5* Einrueckung von 2 Leerzeichen pro Ebene
6* praegnante und viele Kommentare
7* keine lambdas
8* Bei inline-closures die function-Syntax statt der (: :)-Syntax verwenden.
9* else, else if in eine eigene Zeile
10* { am Beginn von Bloecken soll in eine eigene Zeile.
11* Nach ifs, Loops & Co: umfasst der davon kontrollierte Code mehr als eine
12 physische Zeile Code, einen Block mit { } formulieren.
13* keine return fun(), 0;
14* (type) Casts sollten vermieden werden (Ausnahme: (type)call_other).
15 (type) konvertieren nur, wenn die Typen zur Compilezeit bekannt und
16 unterschiedlich sind. Daher bei gewuenschten Konversionen to_type() nehmen.
17* Pfade, die absolut sind, sollen auch mit / beginnen, z.B.
18 inherit "/std/thing", nicht inherit "std/thing"
19
20Benennung von Properties:
21* der interne Name von Properties in der Basis-Mudlib beginnt immer mit
22 "p_lib_". Niemand sonst sollte Properties mit diesem Praefix erstellen.
23
24Sonstiges:
25* In der Mudlib wird keine neue Funktion(alitaet) angeschlossen, bevor die
26 Dokumentation dafuer fertig ist.
27 Am liebsten ist mir, bei der Konzeptentwicklung zuerst die fertige
28 Dokumentation (Manpage) fuer Nutzer/Spieler zu entwickeln, bevor ein Magier
29 ueberhaupt eine Zeile Code schreibt.
30* Patches muessen eine Zusammenfassung haben, welche kurz erlaeutert,
31 was dieser Patch fixen/aendern/verbessern soll und auf welche Weise
32 diese umgesetzt wird. (Anders gesagt: eine Commit-Message)
33
34LETZTE AeNDERUNG:
35 15.8.2015, Zesstra
36