How to hide "if $DEBUG" code?

[J Krugman]

Production code often gets overwhelmed with fragments whose sole
function is to aid development (usually debugging) and have otherwise
nothing to do with the program's logic. This makes it very difficult
to read the code, which in turn breeds its own problems (e.g. code
that is hard to read is also harder to debug, ironically enough).

I realize that the solution to this problem lies mostly in one's
text editor (which in my case is Emacs), but I wonder if there are
Perl tricks/techniques (e.g. coding practices) one can do to
alleviate the problem.

Thanks!

jill

 

[moller]

Production code often gets overwhelmed with fragments whose sole
function is to aid development (usually debugging) and have otherwise
nothing to do with the program's logic. This makes it very difficult
to read the code, which in turn breeds its own problems (e.g. code
that is hard to read is also harder to debug, ironically enough).

I realize that the solution to this problem lies mostly in one's
text editor (which in my case is Emacs), but I wonder if there are
Perl tricks/techniques (e.g. coding practices) one can do to
alleviate the problem.

I usually put a comment # END if $DEBUG and then throw away
everything between when needed.

some code....
if ($DEBUG) {
debug code

 

[Salvador Fandiño]

Production code often gets overwhelmed with fragments whose sole
function is to aid development (usually debugging) and have otherwise
nothing to do with the program's logic. This makes it very difficult
to read the code, which in turn breeds its own problems (e.g. code
that is hard to read is also harder to debug, ironically enough).

I realize that the solution to this problem lies mostly in one's
text editor (which in my case is Emacs), but I wonder if there are
Perl tricks/techniques (e.g. coding practices) one can do to
alleviate the problem.

I use this idiom for debugging code:

dbg_f and dbg "whatever you want $to", @print;

dbg_b and dbg "several channels allow me to debug",
"different things";

where "dbg_f" and "dbg_b" are constants and "dbg" is a "print"
like function that can send its output to a file. They are all
imported from some "MyApp:ebug" module.

As every debugging sentence begins whit "dbg_" they are easier to
recognize and ignore, and less intrusive than using...

print "whatever" if $DEBUG;

.... that only says it is a debugging sentence at the end.

Also using different channels allows me to target different parts
of the program individually for debugging.

I use constants instead of normal perl vars because this way
inactive debugging code is optimized away by perl. I have a
module, ctflags (available from CPAN), that automatically sets
constant values (as dbg_*) from environment variables when the
program is started... unfortunately it is not very user friendly :-(

- Salvador.

 

[Eric Schwartz]

As every debugging sentence begins whit "dbg_" they are easier to
recognize and ignore, and less intrusive than using...

print "whatever" if $DEBUG;

... that only says it is a debugging sentence at the end.

I use a similar convention, developed in a shop I worked in a few
years ago:

DebugMsg($msg); # prints "$0: DEBUG: $msg" if $opt_debug is defined
InfoMsg($msg); # prints "$0: INFO: $msg"
ErrorMsg($msg); # prints "$0: ERROR: $msg"
ProgressMsg($msg); # unusual; prints "$0: $msg"; mostly for semantics
FatalMsg($msg); # same as ErrorMessage, then exit()s
VerboseMsg($msg); # like ProgressMsg, but only prints when $opt_verbose
# is defined.

Offhand, I can't recall why we used FatalMsg instead of die();
probably it was for consistency in both code and printed output
between messages that indicated fatal conditions and those that were
less so.

Anyway, the "nice" thing about DebugMsg($) is that it used a global
variable, $opt_debug, that was set by Getopt::Std, so you could put
all the DebugMsg()s you wanted in the code, and you wouldn't see the
results until you ran "prog -d". Later on, we extended our
conventions to enable -d to take a numeric argument, indicating the
level of debug desired; "prog -d" would give ordinary debug output,
but "prog -d 9" would give you far more than you ever wanted to know
about the internals.

-=Eric

 

[Mark Clements]

I use a similar convention, developed in a shop I worked in a few
years ago:

DebugMsg($msg); # prints "$0: DEBUG: $msg" if $opt_debug is defined
InfoMsg($msg); # prints "$0: INFO: $msg"

<snip>
I like Log::Log4perl. It allows you to configure debug output format and change debug
destination from a central config file. It probably isn't the most efficient of performers
though; I doubt if anything is optimized away...

Mark

 

[Jeff Boes]

I use a similar convention, developed in a shop I worked in a few
years ago:

DebugMsg($msg); # prints "$0: DEBUG: $msg" if $opt_debug is defined
InfoMsg($msg); # prints "$0: INFO: $msg"
ErrorMsg($msg); # prints "$0: ERROR: $msg"
ProgressMsg($msg); # unusual; prints "$0: $msg"; mostly for semantics
FatalMsg($msg); # same as ErrorMessage, then exit()s
VerboseMsg($msg); # like ProgressMsg, but only prints when $opt_verbose
# is defined.

Check out Log::Agent on CPAN. Similar kinds of functionality, lots of
bonus features ...