Lars, I strongly suggest test-driven development. It seems to preemptively do the most relevant of what the debugging rules you quote instruct you to do later. The principles:
- design your interface
- write tests that fail
- write the code to make the tests stop failing
- refactor
- lather, rinse, repeat
It’s a philosophy that anticipates bugs and errors, yet it uses that very fact to guard against them.
Test-driven development has changed the way I (and many others, I learnt it while becoming a Plone developer) plan, design, think about, and implement code. And yet, it’s really not far away from how you’re already doing things. Really.
For C++ coders, I recommend libtut, which is elegant and non-intrusive.
PS: The definitive (and quite good) book on test-driven development by Kent Beck is only 200-something pages, so it’s also in the domain of shorter books.
Update: sorry, liw, for making it sound like I assumed you had spent the last years in a cocoon or cave or curled up in a corner. I didn’t intend to doubt that you know of TDD, just wanted to get that off my mind what your post put there.
And of course, I agree with you: TDD will not eliminate debugging. But it will make your debugging sessions a lot less frequent, even though the really long and painful ones are exactly those that it won’t prevent…
