How to hide "if $DEBUG" code?

Discussion in 'Perl Misc' started by J Krugman, May 4, 2004.

  1. J Krugman

    J Krugman Guest

    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
    --
    To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
     
    J Krugman, May 4, 2004
    #1
    1. Advertising

  2. J Krugman

    Guest

    J Krugman <> writes:

    > 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
     
    , May 4, 2004
    #2
    1. Advertising

  3. J Krugman wrote:
    > 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::Debug" 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.
     
    Salvador Fandiño, May 4, 2004
    #3
  4. Salvador Fandiño <> writes:
    > 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
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, May 4, 2004
    #4
  5. Eric Schwartz wrote:

    > 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
     
    Mark Clements, May 5, 2004
    #5
  6. J Krugman

    Jeff Boes Guest

    Eric Schwartz wrote:

    > 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 ...

    --
    Jeff Boes vox 269.226.9550 ext 24
    Database Engineer fax 269.349.9076
    Nexcerpt, Inc. http://www.nexcerpt.com
    ...Nexcerpt... Extend your Expertise
     
    Jeff Boes, May 12, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. RonL
    Replies:
    0
    Views:
    749
  2. John Black

    can assert() hide debug dump out?

    John Black, Jul 8, 2004, in forum: C++
    Replies:
    2
    Views:
    372
    Phlip
    Jul 9, 2004
  3. ringos75
    Replies:
    0
    Views:
    966
    ringos75
    Apr 14, 2005
  4. Mike C. Fletcher
    Replies:
    3
    Views:
    988
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Oct 12, 2003
  5. André
    Replies:
    3
    Views:
    1,596
Loading...

Share This Page