A Guide to Programming Projects

<< Principles >>

o Always work from a solid code base and make incremental changes.
o If something looks like it will require lots of code, think long and hard
    before doing it because:
    - You might not understand what is required
    - There is a better algorithm
o Refactor your code often to improve clarity and reduce the volume of bugs.

<< Strategy >>

o Preparation

  - Read the project statement.
  - If you are given a code base, understand what is and is not provided.
      Does the code compile and run properly?
  - Try to sketch out the features of your solution (not logic or code).
      Identify the unknowns and the fuzzy parts.  Iterate through these last
      few steps and seek clarification from classmates, consultants, etc.
  - Draw up a development and testing plan; i.e., what will you tackle first,
      second, etc.  Identify the intellectual dependencies.

o Development

  - Insert stderr output to display key variable values at key times.
      Make the output highly visible (e.g., "\t\t+++ eval_bg: ...").
      It would be nice if you can toggle these output statements ON and OFF
      through command line flag(s) or conditional compilation.
  - Low risk code can be inserted into the project code incrementally and
      tested.
  - Write small test programs clarify semantics of complex system calls if
      necessary.
  - If the problem seems too complex, solve a simpler form of the problem.
      But try to select a simplification that will be useful. For example,
      assume one command per line and no variables; and then generalize
      later.
  - Spend time on things that you can leverage in the future.

o Coding

  - See the coding guideline.
  - In short, use a consistent coding style and aim for clarity.
      Myth:  The longer the variable name the clearer the meaning of the
      of the variable.