And, a while after that, there was a meditation... (personally, I think the meditation has more interesting comments attached.)

But before that there was Are debuggers good?, which I still consider the definitive thread on this subject.

Update: Linked to the right post. Thanks, hv.

my $DEBUG = 1;

...

print Dumper(\%x) if $DEBUG;
[download]

Change this to

sub DEBUG () {1}
...
print Dumper(\%x) if DEBUG;
[download]

and the prints will even be optimized away so Perl will not waste time testing the value of $DEBUG at runtime.

Jenda


XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

OK. I'm taking a look at the debugger tut. I think it was probably a bit daunting when I first started the language, print and Dumper are fine for the beginner, but as you get further in more powerful tools start to pay off maybe.

I just find the way of using it, setting breakpoints and so on, to take some getting used to. Then again, I haven't tried for about 2 years so I may give it another shot. Thanks perrin.

But having said that ... where does it really score? I used to write embedded assembler, with that stuff simulators, debuggers, whatever, were almost always worth the effort. But considering that if you add some prints in your code it takes almost no time at all to rerun it, and there are other tools as well to allow you to trace ... where do you score?)

Do you use it on the command line or a graphical version? Maybe a devotee should write a debugger "quick tutorial" that takes straight to the most useful features.

I use the command line. What I discover in the debugger and don't find when using print statements is the path that my code is taking. Sometimes it's not what I thought it was. The breakpoints and stuff are really quite simple. There's a quick reference card here.

The debugger is worth it. It shouldn't be the first tool you reach for, but it shouldn't be far from second.

Amen. For me the biggest problem usage of the debugger is when people use it as the weapon of first resort, without taking the time to reflect on why they need to jump to the debugger.

The only think I'd add is that if you are continually reaching for the debugger then it might be time to reflect on whether there are ways you could introduce a few less bugs (e.g. spend more time refactoring your code for comprehension/maintainability, writing tests first, etc.)

I also use it for debugging, especially small scripts or quick checks or fixes.

I use PerlIDE which, despite a few window management problems and various other bugs, is damn good for debugging. Tooltip evaluation of variable contents using mouse over in the source window. Very nice tree view of arrays, hashes and structures built on those.

Especially while learning Perl interactive debugging in an IDE is very valuable.

It includes facilities for assertions which cause the script to warn() or die() on failure.

To top it all off, it also does animated progress bars (in ASCII of course).

I used to use debuggers quite a bit. However, I found myself writing code without thinking it through, on the theory that whatever I wrote I could clean up using the debugger. This didn't work very well.

Now I use print almost exclusively. The trick is to stop what you're doing and think about what's happening (or not happening). Consider what must happen for things to work out as they do, and then test your idea with a well-placed print statement. Often I use a log file in order to have something I can look at carefully.

I think the decision about whether to use the debugger should not be made on the basis that the debugger is too hard. IMNSHO, one should learn it, and then see how it compares to print statements. Otherwise you may be overlooking a valuable tool. Much depends on personal preferences, and one size does not fit all.

I used to do exactly the same as come of the comments here suggested: print statements, data dumper, and so on

Now I'm going 'agile' by including unit tests from the beginning of my coding, even if inheriting code from others.

In fact, I write tests first, then start coding to make them work. It's a different approach. My 'debugging' time decreased in the end because I was able to find many more mistakes early on.

Give it a try, google on unit testing. There's even a book on Extreme Perl and Test-Driver Design

An example: a simple accumulator. I start with writing Add.t first (the code at the end) and fill up Add.pm (first code on top) to make Add.t run without failures...

A simple accumulator

package Add;

use strict;
use warnings;

sub new {
    my $class = shift;
    my $self = {
        ACC => undef,
    };
    my $closure = sub {
        my $field = shift;
        if (@_) { $self->{$field} = shift; }
        return $self->{$field};
    };
    bless ($closure,$class);
    return $closure;
}

sub acc { &{ $_[0] }("ACC", @_[1 .. $#_]) }

sub add {
    acc( $_[0],acc( $_[0] )+@_[1 .. $#_] );
}

1;
[download]

The test code

use strict;
use warnings;

use Test::More tests => 7;

BEGIN {
    use_ok('Add');
}

ok(my $a = Add->new(),"creation of accumulator");
ok($a->acc(3),"accumulator set to 3");
isnt($a->acc,0,"check if accumulator isn't zero");
is($a->acc,3,"check accumulator equals 3");
ok($a->add(3),"add 3 to accumulator");
is($a->acc,6,"check if add equals 6");
[download]

1. Put something in the print statement to indicate it's temporary.  I use 'TFD' ('Temporary For Debugging'), which is easy for me to search for after I'm through debugging, to take out all of the lines containing it:

     print "TFD>  About to call &parse_results ...\n";
     &parse_results($p);
     printf "TFD>  Done &parse_results, p->[0] = '%s'\n", $p->[0];
   [download]

2. Put reverse-video escape sequences around text to really make it stand out. "<ESC>[7m" will turn ON reverse-video for ansi-capable terminal windows (eg. *nix), and "<ESC>[m" will turn if OFF (this will especially be helpful when you're generating tons of output, as the eyes can quickly spot reverse-video text):

     if ($mystr =~ /Total lines processed:\s+(\d+)/) {
         my $total = $1;
         return $total;
     }
     print "TFD> \e[7mUnexpected format of 'mystr':\e[m\n";
     print "TFD>     '$mystr'\n";
   [download]

I just came across someone's comment about using "warn" for printing out information, instead of print. His reasoning was that it doesn't require newlines, and it isn't affected by buffering - it prints right away. I have yet to try it, but it sounds like a good idea.