CodingStyle

                             Coding Style

The Battletech MUX (and MUSE) source has always been a mess. Part of this is
because of the codebases they built on, others are because writing readable
code is damned hard. However, I would still like to try :) When submitting
patches or commiting changes, please consider the following guidelines:

   - Most of the code is indented using the following indent options:
	indent -kr -i4 -bad -bbb -bap -nbbo -nlp -hnl -br -brs
     (K&R style, 4-space indents, see the indent manpage for the rest.)
     Try to keep your changes in the same style.

   - Try not to combine whitespace/indent changes and code changes in a
     single patch/commit. This makes it very hard to see what actually
     changed. Use two separate patches/commits.

   - For commiters: commit only one fix at a time, with a sensible comment;
     preferably what bug/problem is being fixed, why, how and where.

   - For patch submittors: try to provide sensible information with any
     patches: preferably what bug/problem it fixes, why, how and where.

   - Keep code in easy-to-read chunks. Avoid long if/else clauses or
     multiple flags to carry information from one section of a function to
     another. Today's optimizers are better than what we can hand-hack into
     the code, and a few lines of code duplications are better than stunned
     looks on other people's faces when they try to follow the code.

   - Avoid long C preprocessor macros; more than two lines is generally a
     sign it should really be a function. Don't use function-local data that
     isn't in the argument list for the macro -- this makes rewriting it
     into a function harder.

   - Comments should be ANSI C (C89) comments, '/* */', not C++/C99's '//'.

A lot of the code still violates these, especially the latter two. Fix them
if you happen to touch the code, or take a look at mech.sensor.functions.c or
mech.tech.*.c to see what they can turn into.