do's and dont's

General good programming practices

• Write code that does what it says.
  (example)
  Don't write code to trick the computer into doing something tricky.
• Keep code blocks short (1-10 lines is best, never more than 40). Write functions that do a specific task, can be easily checked that they do that task, and whose name describes the task.
• Do modular programming.
• If you know you will have an efficiency issue, spend lots of time investigating techniques and algorithms that address that, then build your code to accommodate any of the better algorithms.
  As opposed to nailing down the first solution you find, and building the whole code around that one solution.
• "Premature optimization is the root of all evil."
• "length of a variable name should be inversely proportional to its scope"
  If you must have a global, mark it so, and give it an explanatory name.
  If you must have a variable shared from another file, give it a name that says this.
  Often a long name for a variable used on 2 lines is just overkill.
• Compile with the strictest compiler warnings available, strive to make no warnings appear.

What's special to C?

• initialization

  Initialize variables in their declarations.
  Initialize pointers to NULL if nothing else.

• allocation/deallocation

  Be systematic. The simplest system is, in one code block

  	myvar = (type *)malloc( MYVARSIZE );
  	if( myvar != NULL ) {
  		do_something( myvar );
  		free( myvar );
  	}
  

  It is best that only one entity in your program is responsible for a given allocation/deallocation pair.

• structures

  A structure should represent a conceptual entity; members of the structure should be things that are intrinsic to that entity.
  Beware the structure that's just a grab-bag for stuff you might need sometime, or a convenient way to pass variables.

• scope

  Declare functions used only in current file as static.
  Otherwise, namespace pollution results. (Appropriate use of global: An item for which there is exactly one instance for the run of the program for all conceivable versions of the program for all time. That is, almost never.)

• brackets and nested if

  Brackets around individual statements are optional, except in the case of nested if statements.

• constness

  Declare all pointer and array function arguments const unless you mean for the function to change their associated data.

• headers

  Make use of header files to prototype all functions shared by multiple files.

  Each header should include precisely the other headers that are required to describe its contents. That is, an otherwise empty .c file that includes just the one header, should compile.

  One header per .c file is a good rule of thumb. (Finding an appropriate division is a bit of a challenge --Don't cram everything into one header !!!)

  Don't put stuff that will only be used by one .c file in a header. Leave it in the .c file.

• preprocessor

  Proper uses:
  1. #includes
  2. cutting out code (especially, header include guards)
  3. very simple macros: max, min

  Rather than preprocessor symbols. use enum's for constants