A Perl module for better debugging

This simple, elegant module lets you include Perl code for debugging or development-only environments, but hide it for production.
306 readers like this.
annoying bugs


It's occasionally useful to have a block of Perl code that you use only for debugging or development tweaking. That's fine, but having blocks like this can be expensive to performance, particularly if the decision whether to execute it is made at runtime.

Curtis "Ovid" Poe recently wrote a module that can help with this problem: Keyword::DEVELOPMENT. The module utilizes Keyword::Simple and the pluggable keyword architecture introduced in Perl 5.012 to create a new keyword: DEVELOPMENT. It uses the value of the PERL_KEYWORD_DEVELOPMENT environment variable to determine whether or not a block of code is to be executed.

Using it couldn't be easier:

use Keyword::DEVELOPMENT;
sub doing_my_big_loop {
    my $self = shift;
        # insert expensive debugging code here!

At compile time, the code inside the DEVELOPMENT block is optimized away and simply doesn't exist.

Do you see the advantage here? Set up the PERL_KEYWORD_DEVELOPMENT environment variable to be true on your sandbox and false on your production environment, and valuable debugging tools can be committed to your code repo, always there when you need them.

You could also use this module, in the absence of a more evolved configuration management system, to handle variations in settings between production and development or test environments:

sub connect_to_my_database {
    my $dsn = "dbi:mysql:productiondb";
    my $user = "db_user";
    my $pass = "db_pass";
        # Override some of that config information
        $dsn = "dbi:mysql:developmentdb";
    my $db_handle = DBI->connect($dsn, $user, $pass);

Later enhancement to this snippet would have you reading in configuration information from somewhere else, perhaps from a YAML or INI file, but I hope you see the utility here.

I looked at the source code for Keyword::DEVELOPMENT and spent about a half hour wondering, "Gosh, why didn't I think of that?" Once Keyword::Simple is installed, the module that Curtis has given us is surprisingly simple. It's an elegant solution to something I've needed in my own coding practice for a long time.

User profile image.
Ruth Holloway has been a system administrator and software developer for a long, long time, getting her professional start on a VAX 11/780, way back when. She spent a lot of her career (so far) serving the technology needs of libraries, and has been a contributor since 2008 to the Koha open source library automation suite. Ruth is currently a Perl developer and project lead at Clearbuilt.


That sounds like a very promising way to include debug code.
But you should never hardcode configuration data, let alone mix production and test configuration. That will bite you ... hard.

Thirty years of writing code; I know all too well what happens when you hardcode config information. Which is why I said,"n the absence of a more evolved configuration management system." I've had a number of projects which started out with something like this, then iterated and got a more robust config management system, as the needs of the project became clearer.

In reply to by Hendrik T. Voelker (not verified)

I wonder if this method might be used to create a single Perl program which satisfies different purposes, not just as a debugging tool.

A look at the source code for Keyword::DEVELOPMENT will make it clear that you could *totally* use the same or a similar technique for other things.

In reply to by Greg P

This seems to be good technique , thank you for sharing Ruth.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.