C Coding Style Guidelines
We expect you to follow the style rules below.
These are rules that we find useful toward ensuring
that code is readable and that it does what it is supposed
to do in the expected place. Variants of these rules
can be found in various on-line sources (below) that
may be more detailed or may make arbitrary choices
differently. These sources can be interesting reading
because they sometimes justify their rules or have other
smart tricks that you may wish to adopt.
- Write readable code.
- Clear thought leads to clear code.
- Wild, cascading conditionals often indicate unclear thought.
- But often, writing an unclear solution is a good first step toward understanding the problem.
- Use consistent indentation of blocks and function bodies.
- Use a proper editor (emacs, vi) that assists with indentation.
- Prefer to indent by 4 spaces. (set ts=4). (Sufficient for visibity, not so much to waste space.).
- Avoid using the indent command as a last step; it can undo any manual beautification.
- Use Braces; avoid loops and conditionals without them.
- Variable name length should be proportional to scope.
- But avoid globals where they are unnecessary: add function parameters, including "out" parameters.
- Wrap lines manually if needed, simplify with temporary variables if possible.
- Functions may not be longer than 35 lines (roughly a screenful)
- Conversely, functions should represent a reasonable unit of complexity or be reused frequently.
- Too many functions can waste a lot of space.
- Use parentheses for clarity, especially with bit operations.
- Write code that does not confuse the compiler or lead to inconsistent behavior.
- Initialize all variables; the compiler can help with this.
- Malloc and free in visible balance; remember to free if returning with an error.
- Annotate unmodified parameters with const.
- Annotate helper functions with static.
- And annotate methods intended to be used from outside with extern.
- Be clean with warnings. -Wall -Wno-write-strings
- Use -Werror for discipline, though warnings do not always indicate errors.
- Consistent style. For 216:
- k&r (not gnu) braces: opening brace on the same line as the conditional or function, for compactness.
- Capitalize Globals. (but avoid them in general; they are often forbidden in this class)
- ALL_CAPS for #defined constants.
- Use underscores for multi_word_variables, not CamelCase.
- Prefer post-increment to pre-increment: c++, not ++c.
- Use the proper construct.
- Use a for loop when initialization, comparison, and increment are appropriate. (not a while loop)
- Use loop control rather than break; if a loop should end by a condition.
- "infinite" loops should be used for actual infinite loops, not because the break condition is buried.
- Avoid continue
- "continue" is okay if quickly testing a simple case to short circuit the loop.
- Avoid hidden return statements.
- return at the end is okay.
- return at the beginning for erroneous input is okay.
- return in the middle of a loop is sketchy.
- Never copy-and-paste code. Always use a function. Add parameters if needed.
- Functions can have helpers, or accept a few arguments and supply defaults to back-end functions that take more arguments.
- You don't want to have to fix a bug twice.
- Use compound assignment operators when appropriate: a += 3;
- Comment reasonably.
- Describe the intent of a block of code.
- Describe the use of a variable where it is declared, if not obvious.
- Present an example of input being parsed.
- Note /* TODO: */'s as placeholders.
- Avoid describing what a line of code does;
- If the code is too complicated to be read on its own, simplify or split or rename variables.
- Instead describe the purpose of a line.
- Exception: functions that take obscure arguments can be explained, e.g., ioctl.
- All code must have some comments.
- Comments that recite what happens on a line of code ("now call the Foo function") are worse than useless.
- Follow universal convention
- #include <>, then #include "", then #defines, then data types, then globals, then prototypes, then code.
- #defines and #includes in the middle of the code are usually frowned upon.
- main() first or last. (I expect last, but first has its justification)
- Functions should have input parameters before out parameters.
- Save yourself
- assert() facts you believe to be true. e.g., that an object passed as a parameter has been initialized, length values are non-negative, pointers are not null.
- It is better to check for error with assert() than not at all. It's compact in the code, and if you truly believe odd errors shouldn't happen, safe.
- assert() can help with readability, mechanically exposing pre- and post-conditions more strongly than comments (which can become obsolete).
- NOTE, however, that aborting execution may be inappropriate for submitted tests. We likely expect an error message.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (note: for C++)
http://www.pk.org/rutgers/notes/pdf/Cstyle.pdf "C Programming Style" Paul Krzyzanowski