modules ++

frivolous module use --

mom and apple pie ++

Seriously, we favor two kinds of modules --

• objects -- with encapsulated data, public & private methods, and numerous unit tests,
• exported subroutines -- with complex behavior, no side effects, and numerous unit tests

In both case, wrapping it up a module allows cleaner code, easier refactoring, and better documentation. Consider something like this

if (! &valid_foozle_input($wozzle)) {
[download]

versus

if ($wozzle =~ /extensive-perl-regexp-line-noise-here/ {
[download]

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.

just my two cents -- your mileage may vary

water from the great white north