Start motivating yourself by reminding yourself that cut and paste is annoying, slow, and you forget where things should be copied from. Then, write lots of modules, and reuse them. Don't bother cutting and pasting any more, you won't have to!

I'd start by trying to sort your modules out by what they do, and then naming the modules appropriately. Perl has a ton of built in documentation on the subject, and a few monks with better memories than I can probably direct you to the "perldoc" functions on making and using modules. One such document is "perldoc perlmod", but it's not exactly the most intuitive documentation out there.

Templatizing code to accelerate copy-and-paste ability is anti-design, IMHO. It can lead to maintaince problems as well, but more importantly, it keeps one from learning how to perform certain operations without aid of documentation -- and it keeps one from thinking in the realm of new/innovative software design.

If you really have problems with opening/closing files, you need little practice. May be your mind is faster on 'what' part rather than 'how' part. But there is some Perl which is essential and you should atleast read "Learning Perl" or any other basic Perl book as a refresher.

You can write all your essential code in one script use that as a template if you think template is way to go.

artist

Have you considered transforming those snippets in modules? After many reuses of a snippet it should be natural to transform it in something reusable... isn't it? Haven't you find anything interesting on CPAN?

Abigail

This is why I keep telling people I'm NOT a programmer.

--
ellem@optonline.net
There's more than one way to do it, but only some of them actually work.

Some other posts suggest writing modules, which is the normal thing for programmers to do. But as you are
"NOT a programmer" :-)
perhaps the more old-fashioned use of files that contain subroutines for you to reuse would be easier to implement?

For example, in your brand new program that does the day's latest challenge (and perhaps you start with a virtual template of a script that you know functions vaguely similarly) you have something like:

require 'my_general_subs.pl';

my $var1 = shift;
my ( $var2 ) = mgs::get_data( $var1 );
[download]

Then, in a file named my_general_subs.pl that is in one of the @INC directories (thus allowing my_general_subs.pl to be in the current directory), you start with:

package mgs;
[download]

followed by subroutine after subroutine (i.e. no "main" stuff required in this library file, just cool subs that you want to reuse and maybe some initializing statements). Eventually, the file even contains the subroutine you are invoking as in:

sub get_data {
    my ( 
         $name,    # optional comment explaining @name
         $grade,   # optional comment for optional $grade
             ) = @_;

    my $answer;

# Do stuff with $name, $grade, concoct some kind of $answer
# ...

    return ( $answer );
}
[download]

Keeping to the general rule of one package statement per library file (i.e. files like 'my_general_subs.pl' as above), you create several of these library files to contain related subroutines. Suddenly, code reuse becomes a piece of cake! (Check out how to pass filehandles as parameters and also ways of redirecting STDERR to always point to the same file for more robustness here.)

As you are alluding, it's great to write code just once so that you aren't always rewriting the same old thing (also multiple-script maintenance is easier), but since Perl code is fairly easy to generate anew as necessary, you get the best of code reuse without being locked into a one-template-fits-all approach.

'Plan to write your library twice, you will anyway'

which means, because you aren't really sure what you want, or how to do it properly, your first attempt will be OK, but you'll soon wish you had done it differently. Dont worry, do it again, using the lessons AND experience you now have.

'Try to write the interface in a way you think wont need to change'

Hard to do, especially if this is your first attempt. Generalise what you are trying to do. Dont write a 'calculate_fuel_tax()' function or method. Perhaps an 'apply_tax(tax_type)' method is more general, with the _implementation_ doing the gritty work for each tax type.

'Write test cases for EVERYTHING in your library'

In short, if you decide at some point to replace the guts of a method (or entire library), a regression test suite gives you a lot of confidence your dependent code and libraries will still work. Its like replacing your car engine from petrol to electric - as long as all the controls still work the same way, you can drive it exactly the same way.
Use the excellent Test::More and ExtUtils::MakeMaker modules - learn to use them very well, it is well worth the effort - study existing CPAN modules for how they use them

A technical suggestion

'Use hashes as your parameters to methods/functions'

The code becomes self documenting, and more mnemonic. Which is easier to understand and remember

my $result = apply_tax(type         => 'fuel',
                       state        => 'CA',
                       period_start => '01/02/2004',
                       period_end   => '12/02/2004');
[download]

my $result = apply_tax('fuel',
                       'CA',
                       '01/02/2004',
                       '12/02/2004');
[download]

'Plan to write your library twice, you will anyway'

I read this as a citation from "The Mythical Manmonth". The newer edition of this book contains a comment on this idea stating that in fact you need to take into account constant refactoring and sometimes rewriting not necesserilly exactly twice.

Hello. The distinction between library (module) code and script code is important to my answer. I am now using scriptdist and a Vim (my Vi Improved editor) template to automate repetitive coding in my scripts. This is as much templating as I feel I need right now, and it is helping a lot.

If you wonder what is in the Vim template, it is the basic stuff like the perlstarter ("shebang") line and "use strict;" and so on. The scriptdist tool provides supporting files like a MANIFEST and all that (Makefile.PL notably) so that my naked scripts can become installable packages.

scriptdist is perl software by brian d foy and can be found on CPAN

  id/B/BD/BDFOY/

-- 
Cynicism is not "cool" or "hip" or "intelligent". It's like Saddam Hussein's piss mixed
with 004 grit and nitric acid. It's corrosive to everything it touches, destructive to
human endeavors, foul and disgusting. And ultimately will eat away the insides of the
person who nurtures it.

Personally I prefer templates for html only, esp. for creating web based printable reports. For perl code I prefer modules, the monestary happens to have a nice tutorial on this.