doc/bestpractices.txt

   1 Best Practices
   2 --------------
   3
   4 NOTE: this section is very work in progress
   5
   6 PARA Workflow;;
   7
   8  1. Development
   9       * Write a testsuite, build your program with -O0 -g -DEBUG_ALPHA and run
  10         the testsuite under valgrind control. Hack until the program meets the
  11         specifications defined by the testsuite.
  12  2. Beta Test
  13       * Build with desired optimization level and -g -DEBUG_BETA and give the
  14         program to your beta testers.
  15  3. Release
  16       * Build it with optimization and without -g -DEBUG_*
  17
  18 PARA What and when to check;;
  19
  20   * Add REQUIRE checks on your interfaces (incoming parameters). Especially if
  21     an argument might not cover the whole range of the underlying type.
  22   * Don't waste your and your CPU's time with unnecessary checks. The testsuite
  23     should validate your program. NoBug aids in debugging. You can add
  24     Postconditions (ENSURE) and Invariants when you have a bug somewhere and
  25     want to nail it down.
  26   * Added checks don't need to be removed.
  27   * When you use the CHECKED/UNCHECKED features then don't forget C scoping
  28     rules, tag things as CHECKED from the leaves to the root.
  29
  30 PARA Tips & Tricks;;
  31
  32   * TRACE(flagname) at the begin of every nontrivial function will easily log
  33     the progress of your application.
  34   * Trying a RELEASE build will abort on certain conditions (known BUG, TODO's,
  35     UNCHECKED code), you can use this to find these spots.