Programming is not a dry mechanical process, but a form of art. Well written code has an aesthetic appeal while poor form can make other programmers and instructors cringe. Programming assignments will be graded based on style and correctness. Good programming practices usually include many of the following principles:

General Programming Style

• Concise comments that summarize major sections of your code
• Meaningful variable and function names
• Function comments that include: (1) description of what function does; (2) description of input values (parameter values); (3) description of return value(s)
• Well-organized code
• White space or comments to improve legibility
• Avoidance of large blocks of copy-pasted code (use functions!)

Specific Guidelines

Note that re-formatting the code base is not an acceptable method of ensuring that your code matches the pre-existing code.

Code Layout

• Indentation: Use 3 spaces per indentation level, or some consistent number of spaces. Two spaces is probably not enough, more than 6 is probably too many. Note that when you are working in a pre-existing infrastructure, you should use the convention of the existing code base.
  
• Tabs or Spaces: Never, ever, mix tabs and spaces.
  
• Limit lines to 80 characters. This avoids line wrapping. The command
  awk 'length>80' <filename> will print any lines of your code that are greater than 80 characters.
• Blank lines: Use blank lines before and after a function definition, and to separate segments of code. Blank lines should be used to increase readability of your code. Do not separate every two statements by a blank line. 
• Whitespace:
  
• Do not use extra whitespace inside brackets and braces:
• Do this: myFunction(a[2], {1, 2})
• Not this: myFunction(  a[  2 ],   {  1,   2})
• In a function call, do not separate the function name and its argument list by whitespace:
• Do this: myFunction(1)
• Not this: myFunction  (1)
• Use a blank space before and after the = sign in an assignment statement: i = i+1
• Do not include multiple statements on the same line. This reduces readability.
• Separate an in-line comment from the statement by at least 2 blank spaces:
• i = i+1   /* add 1 to i */
•  Don't do this: i = i+1/*add 1 to i*/

• Use a couple of comments before a function or module to briefly describe what the function (or module) does. Likewise, before a chunk of related statements, include comments that describe briefly what the chunk does.
  
• Don't use too many in-line comments. If you feel a need for them, you probably aren't using enough comments at the beginning of functions and complicated code segments.
  

• Begin all variables with a lower case letter, except those that are naming a class or a struct
• All #define-s should be uppercase---multiple words may be separated by underscores.
• Use meaningful names. Except for a loop index, it's rarely a good idea to have a variable i or a variable x. An identifier's name should give the reader a clue about what it represents.
  

Checking Return Values

System calls and library functions provide important information to the programmer via return values. You MUST check all return values and handle errors reasonably.

Initializing Pointers

When declaring a pointer, always initialize it. If you do not yet have a value for it, then initialize it to NULL. This rule is the number one way to avoid memory errors, which can be very difficult to find.