
CODING STANDARDS
================

This file describes how your code must look if you want it included in
the mudlib that is released from Chalmers Datorforening. There are many
advantages to using this standard in all your mud code. For instance
it will be easier for people helping you to see what you have done, and
you will have an easier time reading your own code when you look at it
months after you produced it.

Please note again that the coding standards are volontary for your own
code, but compulsory for everything that is contributed for inclusion with
the mudlib.

This is how your code should look:

- 4 spaces between indentation levels.

- { and } on separate lines.

- One statement per line.

- Long statements should normally be broken over several lines. Normally
  lines should not exceed 80 characters in length. Sometimes it's  more
  practical to have lines longer than 80 characters, and in those cases
  longer lines will be accepted.

- Reserved words should be followed by a space. There should be no space
  between a function name and the following (.

- Operators should be surrounded by spaces. Excetion to this is the ->
  operator which is used on the form a->b.

- All public functions and all functions longer than one line should be
  preceeded by a comment block, looking like the block in the example below.

- All code must be typed.

- The type declaration of a function should be on a separate line.

- ; and , should always be followed by a space, if they do not terminate
  the line.

- There should always be an empty line between the end of one function
  and the header comment for the next function.

- Inside a function empty lines should be used to increase readability.
  It is a good practice to place empty lines between logically separate
  pieces of code.

- Comments should not contain the following characters: '(){}[]
  They clash with the auto-indent in the emacs C++ mode. This mode is
  extensively used in the production and correction of mudlib code.

Example (No warranty of correctness supplied):

/* 
 * A backscratcher example
 * Tintin 920206
 */

inherit "/std/object";

#include <stdproperties.c>

/*
 * Global declarations
 */
static string name;

/*
 * Prototypes
 */
private int scratchback(mixed person);

/*
 * Function name: create_object
 * Description  : Create the object.
 */
nomask void
create_object()
{
    object *objlist, my_obj;
    int i;

    add_prop(OBJ_I_LIGHT, 5);
    objlist = users();
    for (i = 1; i <= sizeof(objlist); i++)
    {
	scratchback(objlist[i - 1]);
	write("You scratch the back of " + objlist[i - 1]->query-real_name());
    }
}

/*
 * Function name: init
 * Description  : Add commands to the player carrying the object
 */
void
init()
{
    add_action("scratchback", "scratch");
}

/*
 * Function name: scratchback
 * Description  : Perform a backscratching operation on someone
 * Arguments    : person - the person whose back is to be scratched
 *                can be an object, a string or 0
 *                if it is 0, you scratch your own back
 * Returns      : 1 - success, 0 - failed to find person
 */
varargs private int
scratchback(mixed person)
{
    if (!person)
    {
	write("You scratch your back.\nIt feels wonderful.\n");
	return 1;
    }

    if (stringp(person))
	person = find_player(person);

    if (!person)
	return 0;

    person->catch_tell(capitalize(this_player()->query_real_name()) +
		       " scratches your back.\n" +
		       "It feels wonderful.\n");
    return 1;
}
				  
