Subroutines and functions save time by letting you reuse code. This six-part series will show you how to create and use them in Perl. This article was excerpted from chapter six of the book Beginning Perl, Second Edition, written by James Lee (Apress; ISBN: 159059391X).
When programming, there will naturally be activities we will want to do again and again: adding up the values in an array, stripping extraneous blank spaces from a string, getting information into a hash in a particular format, and so on. It would be tedious to write out the code for each of these little processes every time we need to use one, and maintaining each code segment would be horrific: if there’s a bug in the way we’ve coded the activity, we’ll have to go through and find each one of them and fix it. It would be better if we could define a particular process just once, and then be able to call on that just like we’ve been calling on Perl’s built-in functions.
This is exactly what subroutines allow us to do. Subroutines (or functions, or simply subs) give us the ability to give a name to a section of code. Then when we need to use that code in our program, we just call it by name.
Functions help our programming for two main reasons: first, they let us reuse code, as described previously. This makes it easier to find and fix bugs, and makes it faster for us to write programs. The second reason is that they allow us to chunk our code into organizational sections. Each subroutine can, for example, be responsible for a particular task.
So, when is it appropriate to use subroutines in Perl? There are two cases when a piece of code should be put into a subroutine. First, you want to include code in a subroutine when you know it will be used to perform a calculation or action that’s going to happen more than once. For instance, putting a string into a specific format, printing the header or footer of a report, turning an incoming data record into a hash, and so on.
Secondly, use subroutines if there are logical units of your program that you want to break up to make your program easier to understand. There is nothing worse than debugging several thousand lines of Perl that are not broken up in any way. Well, maybe one or two things. As an extreme example, sometimes—and only sometimes—it is desirable to have a “main program” that consists entirely of calls to subroutines, like this:
#!/usr/bin/perl -w
use strict;
setup(); get_input(); process_input(); output();
This immediately shows the structure of the program. Each of those four subroutines would, of course, have to be defined, and they’d probably call on other subroutines themselves. This allows us to partition up our programs, to change our single, monolithic piece of code into manageable chunks for ease of understanding, ease of debugging, and ease of maintaining the program.
One note about the term subroutine: in Perl, the words “subroutine” and “function” are synonyms—they both mean the same thing. We will use them interchangeably in this book.