These docs are for newbie wizzes:

    First off, the purpose of this documentation. There is an influx of
non computer science majors into muds. This leads to a variety of
programming styles that are not very easy to read and debug. Therefore,
these documents are written in the hope of setting a standard for
coding styles. These are general guidelines.

Make all long descriptions read well. Try to get atleast 3 lines from them
also. Think of the room in your head and try to describe all you _think_
that you would see there. Make the sentences actual sentances. Not short
choppy things.

All objects in a room mentioned in the long or short_desc are expected to
be described in the items list. If it is a Inn you could expect to find
tables and chairs also.  Maybe even a bar or keg of wine.

Set the light level of the room to something fitting the description. If
you are out in the sunlight a light level of 1 is alright. This is the
minimum required to see with. If you are in a shallow cave of deep pass,
then you might use a light level of 0 where the player would need
one torches. Anything more than that is for deeper down or magic darkness
were even the mood is dark. Should not go lower than -2 though. This is
three torches.

Remember to set the properties in a room if you do not want to have
players fighting, stealing, or teleporting while in that room.

Use clone_list whenever possible. This is used to save memory. A fact to
keep in mind is that if you are creating a hard monster that wanders,
clone_list may not be of use. Clone_list checks the current room
for monsters matching the id given in the list, if it is (found) stop,
if (!found) clone another. ie you could have a wandering monster and end
up with several of them wandering around killing players at random.

Always typedef your functions. This means that you are telling the lib
exactly the variable types you are passing in and expecting back.
    untyped:          _sell(str) {
      typed:          int _sell(string str) { /* expect return of integer */
         or           void _sell(string str) { /* return not expected */
This saves compiler time and effort. Also this will save memory.

If you have no add_action in the room for special actions, be sure to use
the replace_program routine.

Place a smell in the room. Even if it is something about smelling thier own
dirty socks and feet.

Now for the style part. Please note commented examples to help clear
anything in this part up.

Place your closing } on a line by itself. The } should also line up with
the first character that called that particular code block.

Use 4 spaces to indent if possible. A multiple of 2 is encouraged,
but 3 is acceptable. Just be _consistent_.

Place all action functions before the reset before the init. Order them such
that if one calls another, the one called is above the caller.

Recommend: Use define files. these make typing easier on you and reading
easier on the person helping you.

Recommend: All function start with a underscore character. This will eliminate
some lib and code inconsistencies that might arise. So your add_action would
looks like:
     add_action("_help","help");
where you call the function:
     int _help(string str) {  /* give help on given topics */

