C Style Guidelines

General

• NOTE: There are code examples at the end of this page
• 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.
• If variables have the same type, declare them on the same line if possible.
• Leave one blank line between variable declarations and the first line of code in a function.
• Consistent style (e.g., use of curly brackets).
• Do not use CamelCase. Use underscores for multi-word variables. For example, use hot_water_temperature instead of hotWaterTemperature.
• Opening brace must be on the same line as conditional or function.
• Define 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).
• Leave one space after a comma.
• 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.
• If p is a pointer to a structure, you should access members by using p->member rather than (*p).member.
• If p is a pointer to a structure, do not surround the -> operator with spaces (use p->id instead of p -> id).
• You should avoid source lines exceeding 80 characters. You can use the linecheck command in the grace system to verify you have lines with the appropriate length.
• Use the indent utility (after setting the alias we provided) and run it against a copy of your code. Compare the indentation generated by the utility and your original code.
• Take a look at the examples below, so you know what we are expecting when it comes to style.

Code Organization

• Use the universal convention to organize your code:
  1. #include <>
  2. #include ""
  3. #defines
  4. Data Types (e.g., structures)
  5. Globals
  6. Prototypes
  7. Code
• The main() function is either first or last.
• #includes and #defines in the middle of code are usually frowned upon.

Functions

• 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 functions intended to be used from outside with extern.
• Functions should represent a reasonable unit of complexity or be reused frequently.
• If the parameter list extends beyond 80 characters, arrange parameters line by line. Here is an example:

                  void process(int my_first_value, int temperature, float pressure, 
                               int altitude, char color) {
                     /* Code here */
                  }
                  

Comments

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

Miscellaneous

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

Examples

• style_example1.c
• style_example2.c
• style_example3.c

Style Notes (Select the Link)

Additional notes can be found at style notes.

References

• Dr. Neil Spring (http://www.cs.umd.edu/~nspring)
• "C Programming Style" Paul Krzyzanowski
• http://www.cs.arizona.edu/~mccann/cstyle.html
• http://books.openlibra.com/pdf/c_handbook.pdf
• For C++
• http://users.ece.cmu.edu/~eno/coding/CCodingStandard.html

Web Accessibility