Re: Balancing Logging and Code Readability

Here is a performance tip for you: If you have some debug statement that was useful/needed in some low level routine that potentially might get called a million times in the real app, use the "constant" pragma to set the value of your debug flag. (see example below). The advantage is that Perl 5.10 and maybe 5.8?, will detect that the "if" statement below could never be true if DEBUG => 0, and that statement is just not even compiled! So there is no run time check of that flag like there would be if say "if $DEBUG were used.

#!/usr/bin/perl -w
use strict;

use constant DEBUG => 1;

print "this is debug" if DEBUG;
[download]

Update:
I don't know of any "one size fits all" advice for logging. When I write the code initially, I often have lots of print statements so that I can verify that my logical thinking is right and that the code is doing what I think it is doing. I write some code, debug, then take out most of these print statements. Perl compiles and runs so quickly that using "print" is often easier than fiddling with the debugger!

When I release an application to the users, the objective of the logged info is not for me to "debug" the problem meaning know exactly why it happened at a fine level of detail. The objective is for me to have enough information so that I can re-create your problem. Once I can re-create the problem on my machine, then I will figure out "why", maybe by turning on some flags like above in my example.

Comment on Re: Balancing Logging and Code Readability Download Code

Replies are listed 'Best First'.
Re^2: Balancing Logging and Code Readability by saberworks (Curate) on Sep 15, 2009 at 15:36 UTC
Another common thing to accomplish something similar is to declare a vprint() or vwarn() function and have the check for DEBUG only occur there (instead of all over the place in your code). Then you just vprint("debug stuff") everywhere. Still doesn't get rid of the clutter but it ends up being a bit less than trailing if DEBUG everywhere.	[reply]
Re^3: Balancing Logging and Code Readability by ack (Deacon) on Sep 17, 2009 at 02:39 UTC
Very good suggestion and straegy. That strategy can be extended to several other challenges I've encountered with logging...and with debugging, too. In fact, whether one uses logging or (as I noted to Marshall) just straight prints for debugging, gathering the frequently repeated code(s) into subroutines always makes my code much more readable and much less "cluttered." Excellent observation and suggestion. Thanks, saberworks. ack Albuquerque, NM	[reply]
Re^2: Balancing Logging and Code Readability by ack (Deacon) on Sep 17, 2009 at 02:34 UTC
I don't know of any "one size fits all" advice for logging. I totally agree. In fact, I find that "one size" doesn't even work for my own challenges. Thanks for the ideas...especially about `use constants`. I haven't had any reall performance problems with the logging, but I had wondered if there might be a way to handle at least some of the challenge if, in the future, I experienced a performance problem. As I noted in my Update to my original post, I tend to use logging mostly for its flexibility in capturing script progress and capturing script results. I, like you, tend to use print statements for my debugging. At the moment I attribute my preference for prints vs. logging to the reality that I'm still new to the logging capabilities that Log4perl offers. I have presumed that with more experience and understanding I would tend to migrate to using logging for debugging, too. However, I've never had any real problem with using prints for debugging so I haven't really had any strong incentive or desire to migrate away from that strategy. I am, however, experimenting with using logging and have found that it has some interesting and useful contributions to make to my debugging. So, for me, the vote is still out on using logging for debugging. Thanks so much for your reply. I really appreciate it. ack Albuquerque, NM	[reply] [d/l]
Re^2: Balancing Logging and Code Readability by andreas1234567 (Vicar) on Sep 21, 2009 at 10:31 UTC
Here is a performance tip for you: `use constant DEBUG => 1; print "this is debug" if DEBUG;` [download] While this is all well and fine, it can't be changed in run-time. Log::Log4perl has a mechanism is_level that allows for reasonably high performance while allowing configuration changes in run-time (init_and_watch). `$logger->debug("Erroneous array: @super_long_array") if($logger->is_debug());` [download] Benchmark your code and see if you can live with the penalty. Performance is not everything. -- No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]	[reply] [d/l] [select]
Re^3: Balancing Logging and Code Readability by Marshall (Canon) on Sep 23, 2009 at 08:58 UTC
Performance is not everything. Quite true! When you make a logging file, you have to think about how big can it get? And how and when to you "clean it up?". I have log files that I "prune" once per month or even once per year! I have applications where I tell the users to turn on some .cfg flags when they are having troubles. My goal is to get enough info so that I can replicate their problem on my machine. Ok, now that I can replicate the problem, I am in my development environment (super fancy!:, ie Textpad). I can turn on debug things that would otherwise "just bomb" the user system in terms of the shear amount of output. So there are reasons for this "turn on option x, requires changing the code" other than just execution performance, turning some option on might generate so much output that that in itself causes a problem. I allow log options in the ".cfg" file that will be helpful to me in replicating the problem. I have other other options in the code that I use to debug the problem and find out "why".	[reply]


Welcome to the Monastery
	PerlMonks