in reply to Rambling about debuggers

Well, I guess both sides of the coin have a few cons/pros, while "throwing code at a debugger", even if it hasn't been thought through all that well before hand, theoretically sounds like bad practice, having your variable contents, etc. given to you by a debugger, still in essence helps you better understand and think through your code.

Personally, I never used a debugger in Perl, I never could quite figure them out, so I ended up littering my code with print statements like

if (logic = $whatIthoughtitdid) { print "Entered into 1st if statement";
and also following every instance of strings/arrays by print statements giving their contents to me for the umteenth millionth time.

So, whether you think long and hard about your code before hand, or you have an epiphany after the debugger shows you your mistakes, you're still learning what your mistakes were, so once again, the Perl hacker just can't seem to avoid progression.

Replies are listed 'Best First'.
Re^2: Rambling about debuggers
by DStaal (Chaplain) on Jul 26, 2011 at 18:38 UTC

    Mine tend to end up looking like this:

    print STDERR "Debug message\n" if $debug > 0;

    Where the number may change, giving me several levels of debug statements, and $debug gets set by a command-line accumulating switch. I also tend to leave these in production code: Removing a debug statement is a change in code, and any change in code makes it possible to add a bug, after all.

      You can achieve a similar result, but with more flexibility by using Log::Log4perl. In most of my scripts I usually write something like:

      use Log::Log4perl qw(:easy); use Log::Log4perl::Level; Log::Log4perl->easy_init( {'level'=>$DEBUG, 'layout'=>'%m%n'} ); sub doSomething { my $logger = Log::Log4perl->get_logger(); $logger->debug('some message'); }

      As written above, all the logging messages will go to your console, which is the right thing for small scripts that you are actively debugging. Later on you can reduce the log level to $WARN, so that normal debug statements are suppressed, but warnings and errors still appear.

      If your script evolves into something larger or mission critical, then you can take advantage of the expressive grammar available in Log4perl configuration files to have different log levels in different functions, to send logs to files, databases pipes etc, to send you emails on fatal errors, and to change the log level used by a running script, so if it miss behaves in production you can investigate without downtime.