This is what I've done: create a repository, although most of my items are one line fragments and not sub-routines, at present it's got a directory per idiom, but soon it'll be in postgres and fairly cook.

Best practices is a big can of worms, Ideally subroutines should be written like any other code, concisely, legibly etc. Are you asking for details on whether to prototype and such?

I kinda did functions at university in lisp, but in learning the Perl way, I did books, and lo they were good:

• A pretty good book with some generic coding standards is Kernigan and Pikes "Practice of Programming" chapter 2 seperates well-written from beautification.
• "Effective Perl Programming" also has some insights into the matter, highlightig issues with prototypes.
• "Debugging Perl is quite useful on functions, and since reading I've increased my use of return values to return status.
• Damian Conway's "OO Perl" has two blindingly good chapters on what you should already know & what you mightn't already know. There is loads of goodies in there on AUTOLOAD and gifts that can spice up your subroutines ;-)

The only verbal hints I got were, "it's script dummy, check your failures and leave as soon as possible", which works for me.

Now I write functions to be called from a 'jump table' a hash of references to functions, my initial reason for doing this was deprecated when I discovered AUTOLOAD. Other than that I use subs to perfom one overall function and further more low-level functions under that, I like abstraction and subs to be no more than 60 lines ¹.

1. Which is a marked increase from my Lisp days when functions never grew longer than 4 lines.

--

Brother Frankus.