diff --git a/doc/concepts/goodstyle b/doc/concepts/goodstyle
new file mode 100644
index 0000000..15ea04b
--- /dev/null
+++ b/doc/concepts/goodstyle
@@ -0,0 +1,74 @@
+Guter Stil
+ BESCHREIBUNG:
+     Guten Stil kann man lernen. Zumindest in der Programmierung. Guter Stil
+     bedeutet vor allem: Schreib es so, das andere es lesen und verstehen
+     koennen. (Ansonsten werde /secure/-Erzmagier, die muessen aufgrund
+     eingebauter Paranoia selbstverschluesselnd schreiben.)
+
+     Lernen kann man auch am Beispiel, unter /d/gebirge/room/,
+     /d/gebirge/obj/, /d/gebirge/mon/, /doc/beispiele/ ist sauberer Code
+     zu finden.
+
+     Tipps zum Aussehen:
+     - Programmzeilen nicht laenger als 80 Zeichen schreiben, denn 80 Zeichen
+       breite Fenster sind immer noch die Regel
+       - Code kann auf der naechsten Zeile weiterfuehren:
+         filter(all_inventory(environment(TP)),
+		      #'einetollesortierfunktion, &extravariablen);
+       - Strings koennen (ohne Addition mit +) unterbrochen werden:
+         "Jemand "<EOL>    "jammert" == "Jemand jammert"
+         "Jemand \<EOL>jammert"      == "Jemand jammert"
+
+     - Bloecke (mit {} umrandeter Code) einruecken, damit man den
+       geplanten Programmfluss gut erkennen kann
+       - 2 bis 4 Zeichen, nicht gleich ein ganzes Tab (siehe erste Regel)
+       - die { und } ruhig in einzelen Zeilen schreiben
+
+     - Variablen in dem Block deklarieren, in dem sie gebraucht werden,
+       dadurch sind sie schneller zu finden
+
+     - #define nicht uebertreiben, wenn komplexe Funktionen damit gebaut
+       sind, uebersieht der Leser den Code oft nicht mehr
+       - #define sollten in #includeten Headerdateien stehen
+       - wenn es eine oft benutzte Funktion ist, schreib sie als Lfun
+       - ist es vielleicht schon in /sys/*.h oder /secure/*.h definiert?
+
+     Tipps zum Code:
+     - objektorientiert programmieren
+       - das was andere nicht von aussen sehen oder aufrufen muessen, mit
+         "protected" oder "private" bei Vererbung verstecken
+
+     - return mitten im Code wenn moeglich vermeiden, da der Programmfluss
+       damit aufgesplittert wird - ein einziger Funktionsausgang ist
+       uebersichtlicher
+       - Ausnahme hiervon kann aber sein, (die meisten) Ausschlussbedingungen
+         fuer irgendwas am Anfang einer Funktion abzupruefen und die Funktion
+         dann auch sofort zu verlassen.
+      
+     - korrekte Typen bei Variablen und Typen verwenden, damit der Leser
+       erkennt welches Ding was ist
+       - #pragma strong_types oder gar #pragma strict_types hilft
+       - Auch Typpruefungen zur Laufzeit (#pragma rtt_checks) verwenden
+       - bei Objekten, die geerbt werden, immer auch  #pragma save_types
+
+     Tipps zu Dateien:
+     - unterteilt eure Gegenden am besten in verschiedene Verzeichnisse,
+       dann findet man sich schnell zurecht:
+       - NPCs, Objekte, Raeume, Master (ggf. Waffen, Ruestungen wenn zu viel)
+
+     - Pfade sollten in einer zentralen #include Datei stehen, welche dann
+       relativ #included werden kann. Damit erleichtert man spaeteren Magiern
+       eventuell noetige Verzeichnisaenderungen.
+       statt:	AddItem("/d/ebene/<magier>/sumpf/npc/schleimi", ...);
+       lieber:
+         #include "../local.h"
+           [enthaelt ein
+            #define SUMPFNPC(x) ("/d/ebene/<magier>/sumpf/npc/" x)]
+		     ...
+		     AddItem(SUMPFNPC("schleimi"), ...);
+
+ SIEHE AUCH:
+     inheritance, effizienz, pragma, oop
+
+05.06.2014, Zesstra
+