Style Snobbism
When editing someone else's code, always use their indentation and
formatting style, down to the detail. Not only is it annoying to
the author for the style to change, but it makes the code less readable.
Your Friends, the Header Files
In any application that has more than one C file, make a header file
for each that has the prototypes of every non-static function in
that C file. Include the headers both in the C files that use those
functions and in the C file itself, just to check for consistency.
Under no circumstances should you define variables in header files,
even if you have cute macros to only define them in one C file's
include. Define it in the C file and have an extern in the header.
Your Friend, the Compiler
Always compile with full warnings (e.g., -Wall on gcc and -fullwarn
on SGI compilers). Fix
all warnings as they appear, even if you
know that they are not a problem. If you leave warnings unfixed, then
you may not notice a new, valid warning on the next compile.
Function and Procedure Names
Procedures should be named after what they
do, and functions after
what they
return. This statement:
if (checkbounds(i, j)) { ...
isn't nearly as clear as this one:
if (validbounds(i, j)) { ...
Variable Names
Variable names should be kept short and descriptive. Don't use "vc"
or "VertexCount" when "vcount" will do. Similarly, don't use "index"
or "xCoord" when "i" and "x" will do.