C Style Guidelines

General

Good names for variables, constants, and functions.
Good indentation (3 or 4 spaces). Use a proper editor (e.g., emacs, vi) that assists with indentation.
Consistent style (e.g., use of curly brackets).
Do use use CamelCase. Use underscores for multi-word variables. For example, use hot_water_temperature instead of hotWaterTemperature. If you need global variables (avoid them) capitalize the first letter in a multi-word variable (e.g., System_Manager).
Use K&R (Kernighan and Ritchie) braces (not GNU). Opening brace must be on the same line as conditional or function.
Defined values as constants when needed (do not use variables for constants). Do not use numbers in your expressions if those numbers have a special meaning (e.g., 3.1415); instead define constants for them.
#defined constants must be in uppercase (e.g., ALL_CAPS).
In your code you should leave one blank space between operators (e.g., x = 5 + 7).
If the code is too complicated to be read on its own, simplify/split/rename variables.
Use Braces; avoid loops and conditionals without them.
Use parentheses for clarity, especially with bit operations.
Avoid global variables where they are unnecessary.
Initialize all variables; the compiler can help with this.
You should avoid source lines exceeding 80 characters.

You must avoid code duplication by calling appropriate functions (rather than cutting and pasting code).
Input parameters must appear before out parameters.
Annotate helper functions with static.
Annotate unmodified parameters with const.
And annotate methods intended to be used from outside with extern.
Functions may not be longer than 35 lines (roughly a screenful).
Functions should represent a reasonable unit of complexity or be reused frequently.

All code must have some comments (there is no such thing as self-documenting code).
Describe the intent of a block of code.
A description should appear at the top of each function.
Describe the use of a variable where it is declared, if not obvious.

Use assert - Macro that prints error message and terminates the program if the provided expression is false (e.g., assert(x != 0)). Assert can help with readability, mechanically exposing pre and post conditions more strongly than comments (which can become obsolete). Keep in mind that aborting execution may be inappropriate for submitted tests. We likely expect an error message.
About return statements:
- Return at the end is OK.
- Return at the beginning for erroneous input is OK.
- Return in the middle of a loop is sketchy.
About loops:

If a loop should end by a condition, use loop control rather than break.
Use a for loop when initialization, comparison, and increment are appropriate (not a while loop).

Avoid using the indent command as a last step; it can undo any manual beautification.