Of course, everyone has their own style of coding.  And there is
nothing that really makes on style better than another.  The important
thing within a project like this mudlib is that the style remains
consistent so that third parties can find it easy to read all files as
if they had been written by the same person.  This file exists to
document how Nightmare V source code should be laid out.

I. Sections
A source file should be broken up into the following sections:

A. File information
The header comments should look like:
/*    FILENAME
 *    From the Nightmare V Object Library
 *    Brief one line description
 *    Created by YOURNAME DATE (YYMMDD)
 *    Version: %A%
 *    Last modified: %D%
 */

B. System includes
C. Local includes

NOTE: The old prototype in header files is obsolete!  We no longer
prototype in header files.

D. Inherits
E. Attribute declarations
All attributes should be private, and private should be the first
keyword listed.  If it is static, static should be second.
Attributes are lined up in 4 columns:

1                            2               3  4
private (static) DATA TYPE   ATTRIBUTE NAME  =  INITIAL VALUE
private static int           Foo             =  5;

They should appear in alphabetical order.

F. Abstract method declarations
Comment around the abstract methods...

// abstract methods
string GetShort();
// end abstract methods

G. Minimal method prototypes
H. Attribute accessor methods (is/Add/Get/Remove/Set)
Accessor methods for each attribute should be grouped together, with
the attributes appearing in alphabetical order.  For example:
GetLong();
SetLong();
GetShort();
SetShort();
Any isWhatever() methods should be the first ones listed.

I. Modal methods
These are the CanXXX() methods and should appear in alphabetical
order.

J. Event methods
These are the eventXXX() methods and should appear in alphabetical
order.

K. Driver applies
These are the functions that the driver calls.  No object should ever
be written in which driver applies actually do much of anything
(exception: create()).  They should trigger object events or return
object attributes.  Make create() appear first, with the rest in
alphabetical order.

II. Naming Conventions
* Use init caps (InitCaps) for attribute names.
* Use init caps (SetShort) for attribute accessor names.
* Use init caps (CanEvent) for modal methods.
* Use mixed case (eventNameOfEvent) for event names.
* Use lower case underscore (word_word) for driver applies.
* Use lower case underscore for sefuns and efuns.
* Use lower case underscore for local variables.
* File names should be lower case and avoid underscores.

III. Indentation
* Use 4 spaces and not tabs.
* Use the following block style:
    statement {
    }
* Try to keep local variables local to the narrowest block possible
* Always block flow control statements, even if the clause is a single
  statement:
    if( x ) {
        do_something();
    }
    else {
        return;
    }