| 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 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; |
| * (type) Casts sollten vermieden werden. |
| (type) konvertieren nur, wenn die Typen zur Compilezeit *bekannt* und |
| unterschiedlich sind. Eine Alternative sind to_type(), wenn noetig. |
| * Bei Callother in Programmen mit #pragma strict_types muessen deklarative |
| Casts ({type})call_other(...) verwendet werden, um dem Compiler zu sagen, |
| Typ das Ergebnis haben sollte. Der Compiler fuegt an der Stelle im Code auch |
| eine Pruefung ein, welche zur Laufzeit ausgefuehrt wird. |
| * Pfade, die absolut sind, sollen auch mit / beginnen, z.B. |
| inherit "/std/thing", nicht inherit "std/thing" |
| |
| 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 50-60 Zeichen, worum es geht |
| * Eine leere Zeile |
| * Beliebig viele Zeilen mit Beschreibung von max. 70 Zeichen Laenge |
| Dieser Text sollte erklaeren, Warum und Wieso der Aenderung. |
| * 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: |
| 18.2.2018, Zesstra |
| |