How To: Debugging

[scacinto]

I've just started writing my own classes and using them in large chunks of code which calls for serious debugging.  I'm reading the 'debugging-tips.html' help page, which is good, and the 'understanding errors' page which is good if the code actually throws errors.  I thought it might be nice, however, to have a central repository with tips & tricks that the old war-horses have devised to debug their code.  I have nothing to offer at this point, but I'm sure others have tips they can share beyond pointing to the help files.

Will post if I come up with something ingenious.

-S

[scacinto]

while debugging, the non error-throwing gotchas are the hardest to find.  here are a couple I've run across recently.

1) be careful of equivalence, identity, and double-tests in 'if' and 'case' statements.

if ( thisValue.mean == thisValue.mean.exclusivelyBetween(...)...

will not always throw an error, which makes it easy to miss.  You do not need the first part as the .exclusivelyBetween(...) is the test.  SHould look like:

if ( thisValue.mean.exclusivelyBetween(...), { trueFunc...

2) Simple syntax errors which do not throw errors, but fail to act as they should...

     2.do( "printMe".postln; ); // this will print only once.

     2.do( { "PrintMe".postln; } ); // this prints twice as it should.


I'll post more as I find them.

[scacinto]

1) have a "scratch" file that you test your algorithms with, saving after each session afterward with the date, etc.  This means if you forget to change something, or can't remember how you arrived at a certain solution, you will have a working record of your tests.

I have HUGE scratch files which document my progress with each individual piece - each with

// date

stuff


// date

stuff ..

formats which allow me to quickly find solutions to old problems.  They also keep testing code quickly accessible. 
 
2) A good time-saver and a great tool for testing complex algorithms is to write test-code that throws randomized data at your working code.  This will insure that values that fit certain criteria are met and not met from test to test, and if you build in '.postln' to measure the randomized data, you can quickly track what is working, failing, throwing errors or simply acting unpredictably.  It will also save you time typing. 

This also insures that you have a better chance of finding that one combination of values that stumps your code and requires a fix instead of discovering it later during a performance, etc.

[scacinto]

found another cute, errorless syntax gotcha:

where a = some 10000 element list with integers from 1-9
where b = a new list

r = Routine.new({
   10000.do({|i|
      i.postln;
      if(a.at(i) == 1, b.add(1))
      })
   })

will result in List b being filled with 10000 1s. 

r = Routine.new({
   10000.do({|i|
      i.postln;
      if(a.at(i) == 1, {b.add(1)})
      })
   })

...add the appropriate curly brackets required of the 'if statement' and all's well.