Good job on Code Complete. The following is somewhat extracted from there and other sources.

The two criteria for function "goodness" are coupling and cohesion. Cohesion can be thought of as the "internal" make-up of the function - does it do one (or a few small things) well. Coupling is how related one function is to another. The goal is to design/implement functions (or procedures, or methods, or whatever) that have high cohesion and low coupling.

With your second example

func1();
sub func1{
  func2();
}
[download]

That all being said, there are some functions whose sole purpose is to control the flow. Sometimes they're called dispatch functions and other times traffic controllers. (Which is what suaveant explained)

-derby

Something like this was discussed here already...
Everything was discussed here, at least once, right...;-)

Check i.e.: (Software Engr) Encapsulate! No,no,no! Decouple!.

pmas
To make errors is human. But to make million errors per second, you need a computer.

I appreciate everyone's help here. Next time I'll write an example that is more concrete. My attempt at brevity backfired. ;-) Probably what I'm getting at is the use of "dispatch functions." I'm really tring to incorporate local variables, use strict, and passing references between arrays so I'm coming up with some odd questions. I'm a UNIX admin with no formal Computer Science training so I rely on O'Reilly and perlmonks for my information. Thanks again . . . Kevin

sub all_funcs {
  func1();
  func2();
  func3();
}
[download]

                - Ant
                - Some of my best work - Fish Dinner

Part of why subs exist is to ease repetitive tasks w/i code. One applies appropriate style based on need. There will be some instances where option one is best, and others where option two rules.

If you can post a specific example, maybe we can provide a better answer to your somewhat vague question.

HTH
--
idnopheq
Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

~ Shunryu Suzuki

Sorry about the vague question. All three of these functions would be independent in the sense that they do not pass each other data but I would like to execute them in a row. I meant the execution order in my two options to be equivalent. As silly as it seems, something like this:

#!/usr/bin/perl -w

use strict;

func1();
func2();
func3();

sub func1{
  print "I am the first subroutine\n";
  return 0;
}

sub func2{
  print "I am the second subroutine\n";
  return 0;
}

sub func3{
  print "I am the thrid subroutine\n";
  return 0;
}
[download]

The way listed here is the canonical way of calling three completely-independent functions in a row. It is very readable and maintainable.

Maintainable, just to go off on a slight rant, is where there are no hidden assumptions. If you were to do:

sub foo1 {
    foo2();
}

sub foo2 {
    foo3();
}

sub foo3{
}
[download]

I would assume that foo1() depends on the result of foo2() in some fashion. If it doesn't, then I am very confused. Your piece of hidden information here is that there is no dependence between the function, other than they all need to be executed at the beginning of your script.

If you reduce the amount of information that someone needs to know that cannot be directly deduced from reading the logical structure of your code (you do indent logically, right?), that improves the maintainability of your code. Maintainable code should be your holy grail, above and beyond any other consideration (except for correctness). It should be more important than optimization (save for when business needs demand it).

------
We are the carpenters and bricklayers of the Information Age.

Vote paco for President!

func3( func2( func1() ) );
[download]

use subs qw/foo bar baz/;

@_ = ( 1, 2, 3, 4 );

&foo;     # sends current contents of @_
print join(' ', @_), "\n";
&bar;     # sends current contents of @_
print join(' ', @_), "\n";
&baz;      # sends current contents of @_
print join(' ', @_), "\n";
&baz();    # sends an empty list
print join(' ', @_), "\n";

sub foo {
   map { $_++; } @_;    # map actually changes the values in @_
}

sub bar {
    map { $_+=2 } @_;  # again, map changes @_
}

sub baz {
    map { $_--; } @_; # also chainging @_;
}
[download]

I usually prefer to keep the scope levels in mind. Because perl doesnt have a defined main block and some of the subtler uses of scope (anonymous blocks for instance) and BEGIN{} END{} blocks I try to keep things organised so its intuitive. For instance

#!perl
# GLOBAL DEFINITIONS
# TYPEGLOBMANIPULATIONS
# BEGIN{}
# FUNCTIONS
# ANON_BLOCKS
# END{}
# main() equivelent.
__DATA__
[download]

Because this kind of thing can get confusing:

my $var;
sub foo {$var++; #ie code}
my @list;
use Some::Class;
sub bar{}
my %hash;
sub sna{}
sub fu{}
my $scalar;
# code
# ....
__DATA__
[download]

Now you might say "what if a lexical variable is used only by one particular funct ie static lexical" well then I usually do something like this

{ #Anonymous block for the following static lexicals:
  my $static_scalar;
  my @static_array;
  sub push_stack { push @static_array,@_}
  sub pop_stack  { pop @stack}
} #End anonymous block
[download]

So the first would probably end up like this:

use Some::Class;
sub sna{}
sub fu{}
{
   my $var;
   sub foo {$var++; #ie code}
}
{
  my @list;
  sub bar{}
}
my $scalar;
my %hash;
# code
# ....
__DATA__
[download]

Much easier to figure out whats gone 12 months later i assure you. Yves

One other thing to consider is the size (in lines of code) of each subroutine. In my early days as a Cobol programmer, the site standards specified that a subroutine should not be longer than two pages of standard 66 line fanfold printout. That way, you could see the complete subroutine at a single opening of the printout binder. Now, we have long since moved beyond filing out program listings in binders of 132 x 66 sized listings, but the idea still has validity - you should be able to take in the who subroutine at a single reading. Hence, make each routine do a single task - no side effects.

Item. When a single block goes over a page on your editor, your error rate jumps.

Item. When you write your program as a series of functions, it is easy to incrementally test your work as you develop it. Incremental testing helps overall code quality and improves overall development speed.

Item. If you develop your program as a series of functions, if halfway through development you find that you had a logic error, it is generally easier to adjust the overall program flow.

Item. When you make a habit of trying to make your code be more modular and reusable from day one, you start finding a lot more opportunities to reuse code. Reuse is one of those things that you won't find unless you always keep your eyes out for it.

Item. When you call a series of well-named functions, the result is code which clearly documents how it is supposed to work, but without the synchronization issues that scattering excessive comments can lead to. (Note that this is but one documentation need.)

There are more reasons listed at Re (tilly) 1: When do you function?.

Note that this is not a style that I learned, "In school." I studied math in school. Rather this is the style that is common to the best programmers I have run across in the workplace, on CPAN, and in books on good programming organization. Also note that the books on good programming technique that I am talking about are books like Code Complete and The Pragmatic Programmer. These are not books written by academics. Rather they are books written by experienced programmers with years in industry. Admittedly programmers who are willing to pay attention to academic research. But ultimately people whose opinions on programming are strongly influenced by decades of writing code.

If so, then the first important improvement that I would suggest to your style is to use strict.pm and massively reduce the number of globals you use...

I do not maintain that this is the best way to do it, it's just my way....

I like to think of my subroutines in terms of giving instructions.

@lines = &readFile ;
@output = &parseLines(@lines) ;
&doReport(@output) ;
[download]

The reason I use this method is for readability. Read the file to get the lines, parse the lines to get the output, use the output to do the report. It allows me to quickly find the errant code block if there is a problem, and in the design phase I am left with a good outline to build my program around.

Now, on to questions of efficiency, mem footprint, etc... I don't really care. According to my boss, all of the servers work fast enough and I don't. Hence, my main goal is to speed up my work. Also, in a modern computer you should have better than 64MB of RAM, and the space taken up by some of the extra arrays is totally negligible.

Also, look at this write up by Merlyn on references. Passing references to subs will simplify your life at some point.

To redo your example my way:

$f1 = func1();
$f2 = func2($f1);
$f3 = func3($f2);
print $f3;
(or)
print func3($f2);
[download]