blob: 15ea04b603738af57794df50967a7720d3bb662e [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001Guter Stil
2 BESCHREIBUNG:
3 Guten Stil kann man lernen. Zumindest in der Programmierung. Guter Stil
4 bedeutet vor allem: Schreib es so, das andere es lesen und verstehen
5 koennen. (Ansonsten werde /secure/-Erzmagier, die muessen aufgrund
6 eingebauter Paranoia selbstverschluesselnd schreiben.)
7
8 Lernen kann man auch am Beispiel, unter /d/gebirge/room/,
9 /d/gebirge/obj/, /d/gebirge/mon/, /doc/beispiele/ ist sauberer Code
10 zu finden.
11
12 Tipps zum Aussehen:
13 - Programmzeilen nicht laenger als 80 Zeichen schreiben, denn 80 Zeichen
14 breite Fenster sind immer noch die Regel
15 - Code kann auf der naechsten Zeile weiterfuehren:
16 filter(all_inventory(environment(TP)),
17 #'einetollesortierfunktion, &extravariablen);
18 - Strings koennen (ohne Addition mit +) unterbrochen werden:
19 "Jemand "<EOL> "jammert" == "Jemand jammert"
20 "Jemand \<EOL>jammert" == "Jemand jammert"
21
22 - Bloecke (mit {} umrandeter Code) einruecken, damit man den
23 geplanten Programmfluss gut erkennen kann
24 - 2 bis 4 Zeichen, nicht gleich ein ganzes Tab (siehe erste Regel)
25 - die { und } ruhig in einzelen Zeilen schreiben
26
27 - Variablen in dem Block deklarieren, in dem sie gebraucht werden,
28 dadurch sind sie schneller zu finden
29
30 - #define nicht uebertreiben, wenn komplexe Funktionen damit gebaut
31 sind, uebersieht der Leser den Code oft nicht mehr
32 - #define sollten in #includeten Headerdateien stehen
33 - wenn es eine oft benutzte Funktion ist, schreib sie als Lfun
34 - ist es vielleicht schon in /sys/*.h oder /secure/*.h definiert?
35
36 Tipps zum Code:
37 - objektorientiert programmieren
38 - das was andere nicht von aussen sehen oder aufrufen muessen, mit
39 "protected" oder "private" bei Vererbung verstecken
40
41 - return mitten im Code wenn moeglich vermeiden, da der Programmfluss
42 damit aufgesplittert wird - ein einziger Funktionsausgang ist
43 uebersichtlicher
44 - Ausnahme hiervon kann aber sein, (die meisten) Ausschlussbedingungen
45 fuer irgendwas am Anfang einer Funktion abzupruefen und die Funktion
46 dann auch sofort zu verlassen.
47
48 - korrekte Typen bei Variablen und Typen verwenden, damit der Leser
49 erkennt welches Ding was ist
50 - #pragma strong_types oder gar #pragma strict_types hilft
51 - Auch Typpruefungen zur Laufzeit (#pragma rtt_checks) verwenden
52 - bei Objekten, die geerbt werden, immer auch #pragma save_types
53
54 Tipps zu Dateien:
55 - unterteilt eure Gegenden am besten in verschiedene Verzeichnisse,
56 dann findet man sich schnell zurecht:
57 - NPCs, Objekte, Raeume, Master (ggf. Waffen, Ruestungen wenn zu viel)
58
59 - Pfade sollten in einer zentralen #include Datei stehen, welche dann
60 relativ #included werden kann. Damit erleichtert man spaeteren Magiern
61 eventuell noetige Verzeichnisaenderungen.
62 statt: AddItem("/d/ebene/<magier>/sumpf/npc/schleimi", ...);
63 lieber:
64 #include "../local.h"
65 [enthaelt ein
66 #define SUMPFNPC(x) ("/d/ebene/<magier>/sumpf/npc/" x)]
67 ...
68 AddItem(SUMPFNPC("schleimi"), ...);
69
70 SIEHE AUCH:
71 inheritance, effizienz, pragma, oop
72
7305.06.2014, Zesstra
74