jeri_rl:

Yes, I'd suggest that you use subroutines in your subroutines. Generally the CPU impact is insignificant, but it can make maintenance so much simpler. In general, if you use good subroutine names, and restrict subroutines to doing a particular task, it will make your program *more* readable, rather than less.

I try to make a subroutine stick to a particular task, which tends to help keep them short. It also helps keep them reusable. Suppose I have a function called send_report and it loads up a mailing list from the database, formats an EMail, attaches a report and then sends it to everyone on the list. It's not terribly reusable. Sure, if you have to do something similar later, you can copy it and hack it up a bit. Or, you could chop it into smaller, more reusable parts, something like:

sub send_report {
   my ($list, $report, $template) = @_;

   my @recipients = get_list($list);

   my $email = format_EMail($template);
   
   send_EMail( to=>[@recipients], body=>$email, attachments=>[$report]
+ );
}
[download]

This function is pretty easy to read and understand. Sure, the code that does the bulk of the work is in a different subroutine, but that's a feature: If your EMail is formatted incorrectly, you know where to look: format_EMail. You don't have to worry about the code and variables that worries about sending EMail or getting a mailing list.

Another way to determine if your subroutine needs to be split up is to name a subroutine by what it's doing. If you're trying to name a subroutine do_this_and_that, the "_and_" is a tipoff that you need to split it up or that it'll be calling do_this and then do_that.

...roboticus

When your only tool is a hammer, all problems look like your thumb.