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 there is a known efficiency issue, spend lots of time investigating techniques and algorithms that address that, then build the code to accommodate any of the better algorithms.
  As opposed to nailing down the first solution that shows up, 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 a global is absolutely nececessry, mark it so, and give it an explanatory name.
  If a variable must be 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 the 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 that might sometime come in handy, 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 the function is meant 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 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