in reply to Re: RFC: Data::Dumper::Simple
in thread RFC: Data::Dumper::Simple

I'm still coming to a decision as to exactly how I want debug constructs in my code. Looks like I'll have to investigate adding this to my bag'o'tricks.

Some of my code never see's the light of day.
Some goes into highly visible (e.g. your phone bill) production system.

I am trying to establish my own set of guidelines on code 'noise', that doesn't differ by too much across those two disciplines. I know there will necessarily need to be a difference, I want to minimise that difference.

Currently I mainly use STDERR->print(Dumper(...)); in 'private' code, and Log::Log4perl for everything else I think might ever be seen/used by anyone else.

All our internally developed libraries use Log::Log4perl - if someone in the company uses one of our libraries, they need to configure a logger.

Perhaps I am not properly separating the disciplines of logging and debugging - I feel that everything your code reports back is a debug statement - to somebody at some level - some are aimed at developers, some at sysadmins.

use brain;

Replies are listed 'Best First'.
Re^3: RFC: Data::Dumper::Simple
by BrowserUk (Pope) on Aug 01, 2004 at 14:37 UTC

    I understand your dilemma. I've being vacillating between the 'log everything in case it goes wrong' and 'turn it all off for production, cos it slows everything down, causes diskspace maintainance problems, noone ever reads them and thing you need to see is never in the log anyway' camps for 20 years.

    In the early days, processors were slow and disks were small, so logging was minimal by necessity. More recently, disk-space got cheap, compression got better and the processors faster. Extensive logging became attractive.

    I tried it on a couple of projects but came to the conclusion that for the most part extensive logging os pretty pointless. My reasoning goes like this:

    • Faster processors, bigger disks and better compression just mean that you can produce and store stuff that nobody will ever read at an even faster rate.
    • What you need is never in the logs.

      Unless you log every line, variable and every variable change, you always end up adding more logging or turning more of it on and trying to re-create the problem anyway. You might as well leave it all turned off and then turn it on when you need to.

    • In general, the more there is in the log, the harder it becomes to follow it.

      Stage 1) I want a course grained "So far, so good. So far, so good" heartbeat level across the whole application until I can track down roughly where things are going belly-up.

      Stage 2) I want to be able to turn more detail tracing on, bracketing either side of the suspected point of failure--but with everything else turned off. Otherwise you get the "can't see the wood for the trees" syndrome.

      Stage 3) I almost always want to add some extra watches or assertions to track down and the confirm the bug prior to changing the code, and reconfirming after it is fixed.

      Historically, these additions get deleted and have to be put back when the bug (or a new one) reappears. Or they get left in, commented out, and have to be manually reenabled.

    I want to be able to switch tracing on and off across a span of lines, subroutine or package. When if off, it should leave no artifacts in the code.

    Currently, D:SD doesn't easily allow this range-of-lines, or subroutine enablement, but I think that it's filter-based nature lends itself to this modification. The package-level mechanism had me foxed for a while, but thanks to theorbtwo's response to my recent question, I now think I figured out how to do this. I may have a go a tweaking D::SD for lines and subs, and if it seems to work okay, I'll offer the mod back to the author.

    The only other thing missing is a debug level selector.

    1. Heartbeat tick through out the code.
    2. Entry/exit point values.
    3. Major logic flow.
    4. Individual assertions and watches.

    More levels than that and it becomes a labour of love to categorise them--and nobody can agree on the categorisations anyway. Prefereably, the first 3 levels should be install automagically. With the fourth level evolving over time as required, but remaning in-situ in perpetuity.

    At least, that where I think I stand on the subject. Tomorrow I may vascillate again :)

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon