# Other notes on C programming

## 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.