For those of you who instrument your code with debug statements, how do you do it?
And why is your choice the best for you?

Are there any command line conventions for setting the debug level of multiple packages?

My interest relates to fair sized projects.

I plan to use code like the below. One issue is somewhat unsettled, the trade-off between having all the debugging code in the target module versus putting as much as possible in a Debug module. Since debugging code falls outside the domain of normal code normal standards may not apply. Does the encapsulation versus redundancy equation change?

In smaller projects I have often used a simple $DEBUG variable mostly as a boolean. When used as a bit field the only thing I've done that may be unusual is to have a TRASH level to enable the debugging code that is just too embarassing to admit to having used. So TRASH in my code is a weaker version of XXX. When things break in a way I do not expect I quickly get to a point of tossing anything into the debugging output; on review some of the checks seem ridiculous.

For those unfamiliar with XXX. It is an old C convention for marking bad code. I only learned of it at a distance so my usage may be deviant. In my code XXX indicates broken code, ideally there should be no XXX's in my released code. Wrote a stub, mark it with XXX; Algorithm in doubt, XXX; Screen layout deferred, XXX. Some programming editors recognize XXX as a syntactic element of languages.

debugging
Debugging in packages
Perl debugging - a look at 'beta' mechanism
Devel::TrackSub - Subroutine wrappers for debugging

Debugging Perl Program
debugging /logging help

package Off_hand_code;
use Exporter;
use Carp;

our @ISA = "Exporter";
our @EXPORT = qw/ routine /;
our @EXPORT_OK = qw/ set_debug /;

our $debug;    # current debug level


# debugging level definitions

use constant BUG => 1;
use constant TRACE => 2;

use constant ALL => 3;


# Set the $debug variable, complain if new setting is
# not an integer or is out of range (0 thru ALL).
# Tri-nature function.
#
sub set_debug {
    $debug = shift;
    $debug = shift if ref($debug) || $debug eq __PACKAGE__;
    no warnings;
    carp qq/Unexpected debug level "$debug"./ if
        ( $debug < 0 || $debug > ALL ) ||
        ($debug =~ /\D/ );
}


# With no args  return the current debugging level for package.
# With an arg return 0 unless arg is part of current debugging level.
#
sub _debug {
    carp "Wrong number of args to ",__PACKAGE__,"::_debug" if @_ > 1;
    return $debug unless @_;
    return $_[0] if $_[0] & $debug;
    return 0;
}


# XXX  set_debug_output( $output_method) 
# XXX  debug( $level, $output_method, $error_message) 
# instead of Carp::.* etc.

# a routine
#
sub routine {
    warn "debug message" if  _debug && "something";
    warn "trace message" if _debug(TRACE);
}
[download]

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.