| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | Guter 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 | |
| 73 | 05.06.2014, Zesstra |
| 74 | |