/
LIB3/
LIB3/D/ADMIN/
LIB3/D/ADMIN/OBJ/
LIB3/D/ADMIN/ROOM/W/
LIB3/D/HOME/
LIB3/D/HOME/CITY/ARENA/
LIB3/D/HOME/CITY/ITEMS/
LIB3/D/HOME/CITY/POSTOFFI/
LIB3/DOC/
LIB3/GLOBAL/SPECIAL/
LIB3/GLOBAL/VIRTUAL/
LIB3/NET/
LIB3/NET/CONFIG/
LIB3/NET/DAEMON/CHARS/
LIB3/NET/GOPHER/
LIB3/NET/INHERIT/
LIB3/NET/OBJ/
LIB3/NET/SAVE/
LIB3/NET/VIRTUAL/
LIB3/OBJ/B_DAY/
LIB3/OBJ/HANDLERS/TERM_TYP/
LIB3/PLAYERS/B/
LIB3/PLAYERS/N/
LIB3/ROOM/
LIB3/SAVE/
LIB3/SAVE/BOARDS/
LIB3/SAVE/ENVIRON/
LIB3/SAVE/POST/
LIB3/STD/COMMANDS/SHADOWS/
LIB3/STD/CREATOR/
LIB3/STD/DOM/
LIB3/STD/EFFECTS/
LIB3/STD/EFFECTS/HEALING/
LIB3/STD/EFFECTS/OTHER/
LIB3/STD/EFFECTS/POISONS/
LIB3/STD/ENVIRON/
LIB3/STD/GUILDS/
LIB3/STD/LIQUIDS/
LIB3/STD/ROOM/
LIB3/STD/TRIGGER/SHADOW/
LIB3/W/
LIB3/W/BANNOR/
LIB3/W/NEWSTYLE/
These are some style (formatting) guide lines for code on New Moon.  This
is mainly for 'public' code, however if all code more or less follows
these guide lines, it will make it easier for everyone to maintain
code, and for people to help others with coding problems. What
a creator does in his or her own dir is their own choice, though be
prepared for a little light hearted bitching :).
 
These guide lines are intended to make code more readable and maintainable
by all who use New Moon.
 
1) Try to not use tabs in code.  Everyone has a different idea how big
   a tab is, so code will be easier to read if you use spaces.  An indent
   of four spaces is usually fine.
 
2) Comment your code.  For all medium to large functions there should
   be a short comment about what it does.  A comment with the name
   of the function on the same line as the closing curly brace is useful
   to keep track of what you are reading.  Any code that someone
   unfamiliar with the code can't figure out quickly needs a comment.
 
3) For mudlib code, any time any changes are made to a file, the changes
   _must_ be documented.  Either in a comment at the top of the file,
   or in a file of the same base name, with an extension of .log.  Who,
   what, when, and approx line numbers should be included.
 
4) Curly braces should line up vertically, and be at the same indent level
   as the preceding text.  Code in the defined block, should be indented
   one level.  Ie:
     if(..)                      if(..)                     if(..){
     {                not:           {           and not:       foo();
         foo();                      foo();                 }
     }                               }
 
5) Function arguments (both formal and actual) should be set off with
   spaces.  Flow control constructs (if/while/etc) should be
   treated the same way.  Also, the opening left paren should be
   tight up next to the function name or flow control construct.  Ie:
     if( count = 1; count < 10; count++ )
         foo( count, bar );
 
   This makes the variables easier to see.
 
6) There are some places where violating these guide lines is fine, like
   single line functions.  Ie:
     int query_size()    { return 2; }    /* return size of object */