Is it a good idea to create custom modules?

kingman has asked for the wisdom of the Perl Monks concerning the following question:

Here's an example of what I was thinking of doing. I want to start all cgi scripts with this:

# debug mode
BEGIN {
    use CGI::Carp qw(carpout fatalsToBrowser);
    &carpout (\*STDOUT);
}
[download]

I just created a module called Shortcuts.pm that looks like this:

package Shortcuts;
 
use strict;
use diagnostics;
use vars qw(@ISA @EXPORT $VERSION);
use subs qw(debug);
use Exporter;
$VERSION = 1.00;
@ISA = qw(Exporter);
@EXPORT = qw(debug);
 
sub debug {
                use CGI::Carp qw(carpout fatalsToBrowser);
                &carpout (\*STDOUT);
}
 
1;
[download]

So now, when I create a new script, I can just do this:

#!/usr/bin/perl -wT
 
use strict;
use Shortcuts;
# debug mode
BEGIN {&debug}
[download]

This is kind of a minimalist example. But I was wondering: Is this a good idea or does it create 'stylized' code that other people wouldn't want to deal with?

Comment on Is it a good idea to create custom modules? Select or Download Code

Replies are listed 'Best First'.
Re: Is it a good idea to create custom modules? by dragonchild (Archbishop) on Aug 09, 2001 at 18:50 UTC
In short, this is a really good idea ... if done correctly. If done poorly, it will destroy your world in a bad way. My first statement is to not use @EXPORT and instead use @EXPORT_OK. Then, do a `use Shortcuts qw(debug);`. That allows a reader of your code to know exactly where `debug()` is coming from. This is part-and-parcel of self-documenting code. This is one of the bigger discussions in programming theory. I'm in the process of reading Code Complete (which I highly reccomend) and it discusses this very topic in great length throughout the book (of which I'm on chapter 8). Basically, it all depends on a few factors: Are you documenting this? This is the biggest one. Are you using this in a large percentage of places? Are you using this as a repository of common functions? Are they documented? Do you have any globals? If you do, rip them out. Globals in a stand-alone script are arguably justifiable, if absolutely horrid style. If you start using globals across module lines, any reader of your code will rewrite it in disgust. Along the lines of #4, do NOT break the module's encapsulation. Ever. Not even once. Not even jokingly. If you're going through the trouble to create a module to store functionality, use all of its features and make it a black box. That way, if you want to change something across all your scripts (which is what this would allow you to do), you can do so and know that every script will still run, so long as you don't break the contract between the module and the scripts. ------ /me wants to be the brightest bulb in the chandelier! Vote paco for President!	[reply] [d/l] [select]
Re: Is it a good idea to create custom modules? by Masem (Monsignor) on Aug 09, 2001 at 18:52 UTC
There's absolutely nothing wrong with doing this, and it's probably encouraged if you are running several different CGI scripts, as this allows you to do tricks as above, reuse code, set site-wide constants, etc. Just make sure you comment well if you have others that will be looking at the scripts at some point in the future. ----------------------------------------------------- Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain	[reply]
Re: Is it a good idea to create custom modules? by Excalibor (Pilgrim) on Aug 09, 2001 at 23:09 UTC
Hi there, I absolutely agree with dragonchild. It's a good idea to create your own library, actually CPAN is based exactly on the: code re-use and encapsulation of functionality, so both good things (what's supposed to do) and (possible) bugs are well localized and easily tracked down. However, create good modules that don't pollute the main package namespace, document them (POD (`man perlpod`) is good for that, in-place documentation). Use obvious, self-describing names and use them consistently and everywhere they apply, this way your code will be easy to follow for anyone reading it (for once read, every programmer will know what it does in every program you write). Sometime, encapsulating standard modules and pragmas like you do makes things harder to read until you get used. Some people like to be very explicit about imports and anything that may affect the way a program runs, but if you are comfortable with it, just go ahead, document it well and use it everywhere it's sensible... I, particularly, don't like to export anything, and prefer to fully qualify names so there's no confusion about where this function came from, etc, but as this can easily become too verbose, some standard, well known modules, may be `use`d without fear, although @EXPORT_OK is cleaner for this. Good luck! `our $Perl6 is Fantastic;`	[reply] [d/l] [select]