Subroutines and Functions in Perl

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 infor mation 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;


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.

{mospagebreak title=Understanding Subroutines}

Now that we know what subroutines are, it’s time to look at how to define them and how to use them. First, let’s see how to create subroutines.

Defining a Subroutine

We can give Perl some code, and we can give it a name, and that’s our subroutine. Here’s how we do it:

sub example_subroutine {
.. .

There are three sections to this declaration:

  1. The keyword sub
  2. The name we’re going to give it. The rules for naming a subroutine are exactly those for naming variables; names must begin with an alphabetic character or an underscore, to be followed by zero or more alphanumerics or underscores. Uppercase letters are allowed, but we tend to reserve all-uppercase names for special subroutines. And again, as for variables, you can have a scalar $fred , an array @fred , a hash
    %fred , and a subroutine fred() , and they’ll all be distinct. 
  3. A block of code delimited by curly braces, just as we saw when we were using while and if . Notice that we don’t need a semicolon after the closing curly brace.

After we’ve done that, we can use our subroutine.

Before we go any further though, it’s worth taking a quick time-out to ponder how we name our subroutines. You can convey a lot about a subroutine’s purpose with its name, much like that of a variable. Here are some guidelines—not hard-and-fast rules—about how you should name subroutines:

  1. If they’re primarily about doing something, name them with a verb—for example, summarize() or download()
  2. If they’re primarily about returning something, name them after what they return—for example, greeting() or header()
  3. If they’re about testing whether something is true or not, give them a name that makes sense in an if statement; starting with is_… or can_… helps, or if that isn’t appro priate, name them with an adjective: for example, is_available() , valid() , or readable()
  4. Finally, if you’re converting between one thing and another, try and convey both things— traditionally this is done with a 2 or _to_ in the middle: text2html() , meters_to_feet() . That way you can tell easily what’s being expected and what’s being produced.

Google+ Comments

Google+ Comments