note
water
modules ++<p>
frivolous module use --</p>
mom and apple pie ++ </p>
Seriously, we favor two kinds of modules --
<ul>
<li>
objects -- with encapsulated data, public & private methods, and numerous unit tests,
<li> exported subroutines -- with complex behavior, no side effects, and numerous unit tests
</ul>
In both case, wrapping it up a module allows cleaner code, easier refactoring, and better documentation.
Consider something like this
<code>
if (! &valid_foozle_input($wozzle)) {
</code>
versus
<code>
if ($wozzle =~ /extensive-perl-regexp-line-noise-here/ {
</code>
The former clearly indicates what is going on, the documention on what makes something fozzle_valid can go into the module (sub or object, depending), you can now write unit tests against the sub, you can use the sub in numerous places across the codebase (instead of just in this file, as a local sub would require), not have repeated code, etc.
<p>
just my two cents --
your mileage may vary
<p>
[water] from the great white north
382202
382202