Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Style & subroutine organization

by Anonymous Monk
on Aug 29, 2001 at 22:32 UTC ( #108836=note: print w/replies, xml ) Need Help??

in reply to 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:


'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.

Replies are listed 'Best First'.
Re (tilly) 2: Style & subroutine organization
by tilly (Archbishop) on Aug 30, 2001 at 00:48 UTC
    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://108836]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (9)
As of 2019-11-18 17:00 GMT
Find Nodes?
    Voting Booth?
    Strict and warnings: which comes first?

    Results (90 votes). Check out past polls.