Re: Program structure: subs vs modules vs Selfloader

From a more general point of view, when having to decide whether one should "spin off" a subroutine in a module, I always ask myself "What are the chances that this subroutine or subroutines need(s) to be called from another script?"

If the subroutine is only useful in this script, I leave it in. With the modern IDE's you can usually "fold" these subs out of sight, so they don't get in the way.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Comment on Re: Program structure: subs vs modules vs Selfloader

Replies are listed 'Best First'.
Re^2: Program structure: subs vs modules vs Selfloader by ctilmes (Vicar) on Jun 21, 2004 at 11:56 UTC
If the subroutine is only useful in this script, I leave it in. For any sizeable project, I have a tendency to go the other way and put virtually all of the functionality of the program into Modules. The front end program(s) just parse command line options and call the right modules. They also hold the POD documentation for the end user. The Modules have the POD documentation for their API. Then it is really easy to have separate front end test scripts that set up certain conditions and call the modules the same way the real front end program does. I figure even if the module never gets re-used, it is still nice to have a clean well-documented API to it that can be easily exercised by test scripts.	[reply]
Re^3: Program structure: subs vs modules vs Selfloader by CountZero (Bishop) on Jun 21, 2004 at 16:11 UTC
Well, that is the power of Perl: TIMTOWTDI! CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]