diff --git a/doc/driver/codestyle b/doc/driver/codestyle
new file mode 100644
index 0000000..78a05b6
--- /dev/null
+++ b/doc/driver/codestyle
@@ -0,0 +1,247 @@
+    The LPMud gamedriver is by nature the result of the cooperative work
+    of multiple programmers, often separated by large oceans and years
+    of time. In order to keep the appearance of the driver source consistent
+    (and with that maintainable), the following guidelines should be followed
+    for all code contributions.
+
+    For a quick start in how good driver source should look like, take
+    a look at comm.{c,h}, object.{c,h} and mapping.{c.h}.
+
+    The guidelines have a strong emphasis on code layout and commenting,
+    stemming from the fact that proper layout and comments gave the
+    incentive for LDMud in the first place. Right now, 50% of all lines
+    are comments, and that has been proven to be a Good Thing.
+
+    Any reader of the "real programmers don't write comments"-school
+    of thought is asked to take his or her incompetence elsewhere.
+
+
+Language
+--------
+    The language is ISO Standard C (also known as 'C89' or 'ANSI C').
+    Common compiler extensions or features from the new C99 standard are
+    permitted if their addition is transparent for other C89 compilers.
+    For example: the 'inline' keyword permitted through the use of the
+    INLINE macro; so are the Metrowerks-pragmas and GNU-attributes. Not
+    permitted are GNU's local functions.
+
+    System/Platform specifics are to be detected by the configure script
+    and provided with transparent implementations in port.{c,h} (or for
+    module-specific dependencies in the respective modules).
+
+    Adherence to the Standard has the following implications:
+
+     - All functions must be fully prototyped.
+     - Standard types like size_t, ssize_t or ptrdiff_t are to be used
+       whereever possible.
+     - Unixisms like
+         {
+           a = malloc(20);
+           b = malloc(20);
+           c = b-a;
+         }
+       are not legal and shouldn't be used.
+     - Don't make assumptions about the size of the base types (e.g.
+       a char might have more than 8 bits). If such an assumption
+       is unavoidable, comment it clearly and if possible add a test
+       to raise a compile or runtime error if the assumption is not met.
+
+
+Style
+-----
+    All modules (.c-files) have to have their interface in an accompaning
+    .h-file. The header file must be guarded against repeated inclusion
+    with the normal
+        #ifndef HEADERNAME_H
+        #define HEADERNAME_H 1
+          ...
+        #endif /* HEADERNAME_H */
+    construct. To use a module, its headerfile must be included - no random
+    'extern' declarations.
+
+    Every module must include "driver.h" which in turn includes the
+    portability headers and provides common defines.
+
+    Use the driver-provided types and macros like Bool or p_int.
+
+    Code should be written defensively and readable. This is not the IOCCC.
+
+    No magic numbers - use #defines to give them names.
+
+    Add sanity checks where useful. If the checks are costly, enclose
+    them in a #ifdef DEBUG...#endif bracket.
+
+    Comment questionable code or opportunities for possible extensions with a
+    'TODO: ...' comment. For multiline comments, use 'TODO::' on the second
+    and following lines (this makes reading a grep easier).
+
+    Comment temporary debug code with a 'DEBUG:' comment. Similar, debug
+    output should always begin with 'DEBUG:'.
+
+    Variable identifiers should start with a lowercase letter, function
+    identifiers may start with upper or lowercase, constant identifiers
+    should start with an uppercase letter. Macro identifiers should be
+    all UPPERCASE, other identifiers may be under_scored or SkudlyCaps.
+    Hungarian notation is accepted only in a very light form: pFoo for
+    pointers, ppFoo for pointer to pointers, iFoo for integer types,
+    sFoo for string pointers, aFoo for complex types - you get the
+    idea. But no alpzsFoo and friends.
+
+    f_xxx() function names are reserved for efun implementations.
+    typedef'd typenames should end in _t (e.g. 'mapping_t'), struct
+    names should end in _s (e.g. 'struct instrs_s').
+
+    Indentation is 4 spaces per level. No tab characters anywhere!
+
+    The indentation style is a variant of the 'Allman style':
+
+        if (foo)
+        {
+            ...body...
+        } /* if (foo) */
+
+    Note the comment at the closing brace!
+
+    One line bodies may be written as
+
+        if (foo) body;
+
+    or
+
+        if (foo)
+            body;
+
+    _if_ it improves the readability.
+
+    Similar, the typical layout of a function is:
+
+        static int
+        function_name ( arg1 , arg2)
+
+        /* Twiddle <arg1> with <arg2> and return the result.
+         */
+
+        {
+            ....
+        } /* function_name() */
+
+    If an expression (argument list, ...) extends over several, the first
+    literal element on a line should be an operator or syntactical marker:
+
+        if (condition1
+         && (   condition2
+             || condition3)
+           )
+
+        printf( "..."
+              , arg1, arg2, arg3
+              );
+
+    Be generous with whitespace - both horizontal and vertical.
+
+    [ The reasoning behind this style is to use the language elements
+      to create strong visual structures for the eyes to follow. By doing so,
+      the structure of the program becomes obvious without much
+      conscious thought.
+    ]
+
+
+Commenting
+----------
+    The comments also follow the idea of giving strong visual clues of
+    how the program is structured.
+
+    Horizontal lines should be created as
+
+        /*------...-------*/
+        /*======...=======*/
+        /* - - -... - - - */
+
+    The '---' line is the normal separator between the components of a
+    source file (includes, variable declarations, macro declarations,
+    the separate functions). The '===' line can be used to separate
+    larger sections of a source file (e.g. the lowlevel routines from
+    the efun implementations). '- -' lines, which usally span less than
+    the whole line, can be used to subdivide large functions (though then
+    it's often better to split the function into several small ones).
+
+    A '***' line is reserved for the end of every source file.
+
+    A '/* --- Subsection --- */' is also good to separate subsections.
+
+    Vertical lines are to be constructed as
+
+      /*
+       *
+       */
+
+    No box comments.
+
+    Every function must have a head comment explaining the meaning
+    of the arguments, what the function does, and the possible results.
+    For efun implementations, this comment should be identical to the
+    man page.
+
+    Within a function, every variable should be commented as
+
+       int foo;  /* short comment */
+       int bar;
+         /* long comment which doesn't fit on one line.
+          */
+
+    The major steps in a function should be preceeded by a comment
+    explaining them. Also, wherever a critical design decision has
+    been made, a comment should line out the whats and whys:
+
+        /* Duplicate the stored arguments for the function call.
+         * (It's tempting to use the stored arguments directly
+         *  in the last pass; however it's not guaranteed that
+         *  the last pass actually comes this far.)
+         */
+
+
+    A typical file layout, commentwise, looks like this:
+
+        /*------------------------------------------------------
+         * Gamedriver Bouncing module.
+         *
+         * <reserved for future copyright notice>
+         *------------------------------------------------------
+         * 'Big picture' description of the module and its
+         * relation to the other gamedriver parts.
+         *
+         * Tricky design discussions also belong in here.
+         *------------------------------------------------------
+         */
+
+        #include "driver.h"
+        #include "typedefs.h"
+
+        #include <stdlib.h>
+
+        #include "bounce.h"
+        #include "backend.h"
+
+        /*--------------------------------------------------------*/
+
+        /* --- User information --- */
+        interactive_t *all_bouncers[MAX_PLAYERS];
+
+        /* ---  Statistics --- */
+
+        p_int number_of_calls;
+
+        /*--------------------------------------------------------*/
+        void
+        add_bouncer (interactive_t *bouncer)
+
+        /* This function adds <bouncer> to the all_bouncers[].
+         */
+        {
+            int i;  /* search index */
+
+            ....
+        } /* add_bouncer() */
+
+        /**********************************************************/
+