This is somewhat personal style - but these are the levels I tend to migrate through.
First of all I write all of my code test first. I moved over to this style a couple of years ago. I find it gives me a far better knowledge of my code state, so I spend far less time sprinkling debug statements around.
The stuff that you mark with XXX I would mark by a failing test or a TODO test (the latter being an exceptionally neat feature of Perl's testing framework not found in the systems I have used in other languages).
If I've got a quick question about what $foo is at some point in my code I'll just add:
warn "foo is $foo";
and delete it as soon as I have an answer to my question.
I only do this when I'm sorting unit tests. Code with debug warnings in never hits the CVS tree.
If I need to leave the debug statements in for a bit I stick a constant into the module.
use constant DEBUG => 1; ... warn "foo is $foo" if DEBUG; warn "bar is $bar" if DEBUG > 2; ...
Again, I only use this when I'm sorting unit tests. Code with warnings can hit the CVS tree, but only when DEBUG => 0.
If I have bugs during integration and need to switch debugging info on and off in several modules I will use some variant of Poor man's logging.
Anything more complex means that I'm in the realm of logging, rather than debugging so I'll use a proper logging module like Log::Log4Perl.
In reply to Re: Instrumenting code for debugging.
by adrianh
in thread Instrumenting code for debugging.
by rir
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |