So that the C code that one person writes is easily understood by
everyone, I suggest we follow the following standards when programming
in C.

a) Everyone should use the following type prefixes for their
   variables:

   vct	   - VECTOR
   pl	   - POLY
   trm	   - TERM 
   sc	   - SCALAR
   exp	   - EXPR
   b       - BOOL
   et	   - EQNTYPE
   eqn	   - EQN
   s       - string (array of characters)
   c	   - character
   xcl	   - XColor
   xfs	   - XFontStruct
   xcs	   - XCharStruct
   xsh	   - XSizeHints
   p<type> - pointer to <type>
   pf	   - file pointer
   a<type> - array of <type> 

   Thus one should define "pvctInitial" for a pointer to a vector
   named "Initial".  Anyone creating new types should use typedef's
   and define the type name in all capital letters.  For these new
   types we should think up a two or three character type prefix and
   add it to the above list.  Do not use type prefixes for integers as 
   these are the default type.

b) All structure types should be passed by reference (via the '&'
   operator) in order to save the time that would be spent pushing the
   entire structure on the stack.  However, the called function
   shouldn't modify the passed structure unless the function header
   says that it does. Functions that need to return a structure should
   have a structure passed by reference and fill in that structure
   with the information to return.  In other words, the function
   shouldn't "return" anything, but just change a structure passed to
   it; alternatively, the function should return a pointer to the
   structure (this would be appropriate for functions working on
   linked lists or trees).

c) All functions should have header comment blocks that look like the
   ones already written.  There should be two blank lines between
   different functions.

d) Functions which aren't general (i.e., only work when NUMBER_OF_VARS
   is #defined to be three) should be documented as such and
   preferably should print out an error message and exit if they are
   called under circumstances that they can't handle (i.e., if they
   are called when NUMBER_OF_VARS is not three).  When possible, such
   functions should be written so that only the function itself need
   be rewritten to make it more general, not the calls of this
   function.  In other words, the function should have the same
   parameters for the general case as the specific case.

e) Things should be generally well commented.

f) The programs should be user friendly.  For example, routines which
   use "argv" and "argc" to process command line parameters should
   check the correctness of these parameters and print out a UNIX-like
   "usage:" message if they aren't correct.  It's best to avoid core
   dumps whenever possible.

g) All lines in the source code should be less than eighty characters
   long.

Everyone should feel free to comment on these standards.  When we
think up new standards we should modify this file and send out E-mail
notifying everyone of the change.

							Bret

