Re: Style & subroutine organization

It drives me nuts when guys seperate their programs into multiple subroutines for no good reason, and I get especially excercised when you interleave the subroutine definitions with the main code which calls them.
If you _really_ want to make me crazy, nest each function within the previous one to add needless complexity! I can't believe they taught you to do that in school.
If these subroutines are doing significantly different or reusable things, maybe. Otherwise just make it all one long block.
I'm NOT encouraging you to make all the variables global. you can certainly scope your variables within the blocks of code in which they're used. Heck, enclose the blocks in braces {} to limit the scope of a variable, but they DON'T have to be functions!
Take this:

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

'twas indented, but the silly formatter mashed that....

sub func1
{
my $variables;
}
sub func2
{
my $more_variables;
}
sub func3
{
my $other_variables;
}

and eliminate everything but the braces:

{
my $variables;
# Code to use these variables
} # End of scope of $variables
{
my $more_variables:
# Code uses more_variables
} # End of scope of $more_variables
{
my $other_variables
# Use other_variables
} # end of scope of $other_variables.

I usually find myself making enough blocks in braces as a "natural consequence" of conditional statements and other flow control to not have to add additional braces to control the scope of my variables.

Comment on Re: Style & subroutine organization

Replies are listed 'Best First'.

Re (tilly) 2: Style & subroutine organization
by tilly (Archbishop) on Aug 30, 2001 at 00:48 UTC

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.

[reply]


There's more than one way to do things
	PerlMonks