I find this also. Though I don't have it down to a habit yet. I may write test or code first. I also find testing to eliminate much debugging effort. I usually have an editor on the test file and the code file, write a little, test a little, and vice versa. If I know where I'm going I'm apt to write the test first. When I'm in cut and fit mode, writing tests first seems inefficient.
Part of this is a prejudice toward testing small chunks of code, then writing tests for those pieces as a unit.
I will consider using TODO tests, thanks adrianh. My XXX's mark the location of the bad code, and it is known to be bad. (That statement demonstrates that I have not internalized the XP attitude to testing.)
It is more flexible to use bitfields instead of additive levels.
Thanks Poor man's logging is one nice answer to my command line query.
More and more, I lean towards leaving in all the debugging code. If I wanted to check warn "foo is $foo"; why wouldn't I want to leave that pointer for the next reader. There are times that the code is changed and a debug statement becomes superfluous. But in general it is like marking a trail for the next person.
In reply to (Re:)+ Instrumenting code for debugging.
by rir
in thread Instrumenting code for debugging.
by rir
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |