By and large, function parameters fall into one of three categories:

• Primary data -- what the code actually crunches.
• Switching parameters -- options that regulate the crunching.
• Tramp data -- information the function doesn't use at all. It's just passing through on its way to another function.

To illustrate those three ideas, let's look at a toy program:

    sub print_multiple {
        my ($count, $string, $format) = @_;

        for (1..$count) {
            print &format_string ($string, $format), "\n";
        }
        return;
    }

    sub format_string {
        my ($string, $format) = @_;

        my %templates = (
            'bold'   => '<b>%s</b>',
            'italic' => '<i>%s</i>',
        );

        return (sprintf ($templates{$format}, $string));
    }

    &print_multiple (5, 'hello, world.', 'bold');
[download]

In print_multiple(), $count is a switching parameter, while $string and $format are tramp data.

In format_string(), $string is primary data and $format is a switching parameter.

The whole point of using functions is to isolate tightly-cohesive bits of logic so you can call them from other parts of the program. That gives you primary data. Then you want your functions to be general enough that they're useful in lots of settings, which gives you switching parameters. Then you build high-level functions that call low-level functions, but you still have to get all the parameters to the low-level code, which creates tramp data. Then the whole thing gets so convoluted that you can't keep track of it any more, and you start buying books about OOP.

The way to break out of that trap is to think about data independently from the logic. Instead of thinking "what parameters does this function need?" think "what does this information describe?". Assemble your data in coherent structures, then pass those structures to functions that use whatever information they need.

Applying that concept to the toy program gives us this:

    sub print_multiple {
        my $b = shift;

        for (1..$b->{'count'}) {
            print &format_string ($b), "\n";
        }
        return;
    }

    sub format_string {
        my $b = shift;

        my %templates = (
            'bold'   => '<b>%s</b>',
            'italic' => '<i>%s</i>',
        );
        return (
            sprintf (
                $templates{ $b->{'format'} }, 
                $b->{'string'}
            )
        );
    }

    $block = {
        'string' => "hello, world.",
        'format' => "bold",
        'count'  => 5,
    };
    
    &print_multiple ($block);
[download]

Instead of dealing with random data, we now have a structure that represents a block of formatted text. We can add other attributes to that structure if we need to, without imposing any change on the functions we already have. Heck, we can store it and use it again, which isn't true for the previous version.

The control flow and logical structure of a program are only one half of the story. The data model is the other half. Instead of worrying about how you're going to get parameters into a function, work out a data model, then build your logic to fit that model. Put the burden of organizing information into the data structures where it belongs, instead of smearing it out across your function signatures. You'll find that your parameter lists shrink dramatically, and that your functions will be easier to write.