Learning Perl, 5th Edition

Chapter 4. Subroutines

You’ve already seen and used some of the built-in system functions, such as chomp, reverse, print, and so on. But, as other languages do, Perl has the ability to make subroutines, which are user-defined functions.^[10] These let us recycle one chunk of code many times in one program.^[11] The name of a subroutine is another Perl identifier (letters, digits, and underscores, but it can’t start with a digit) with a sometimes-optional ampersand (&) in front. There’s a rule about when you can omit the ampersand and when you cannot; you’ll see that rule by the end of the chapter. For now, we’ll just use it every time that it’s not forbidden, which is always a safe rule. We’ll tell you every place where it’s forbidden, of course.

The subroutine name comes from a separate namespace, so Perl won’t be confused if you have a subroutine called &fred and a scalar called $fred in the same program—although there’s no reason to do that under normal circumstances.

Defining a Subroutine

To define your own subroutine, use the keyword sub, the name of the subroutine (without the ampersand), then the indented block of code (in curly braces),^[12] which makes up the body of the subroutine, something like this:

sub marine {
  $n += 1;  # Global variable $n
  print "Hello, sailor number $n!\n";
}

Subroutine definitions can be anywhere in your program text, but programmers who come from a background of languages like C or Pascal like to put them at the start of the file. Others may prefer to put them at the end of the file so that the main part of the program appears at the beginning. It’s up to you. In any case, you don’t normally need any kind of forward declaration.^[*] Subroutine definitions are global; without some powerful trickiness, there are no private subroutines.^[†] If you have two subroutine definitions with the same name, the later one overwrites the earlier one.^[‡] That’s generally considered bad form, or the sign of a confused maintenance programmer.

As you may have noticed in the previous example, you may use any global variables within the subroutine body. In fact, all of the variables you’ve seen so far are globals; that is, they are accessible from every part of your program. This horrifies linguistic purists, but the Perl development team formed an angry mob with torches and ran them out of town years ago. You’ll see how to make private variables in Private Variables in Subroutines,” later in this chapter.

---

^[10] In Perl, we don’t generally make the distinction that Pascal programmers are used to, between functions, which return a value, and procedures, which don’t. But a subroutine is always user-defined, while a function may or may not be. That is, the word function may be used as a synonym for subroutine, or it may mean one of Perl’s built-in functions. That’s why this chapter is titled Subroutines, because it’s about the ones you can define, not the built-ins. Mostly.

^[11] The code examples used in this book are recycled from at least 40% post-consumer programming and are at least 75% recyclable into your programs when properly decomposed.

^[12] Okay, purists, we admit it: the curly braces are part of the block, properly speaking. And Perl doesn’t require the indentation of the block—but your maintenance programmer will. So please be stylish.

^[*] Unless your subroutine is being particularly tricky and declares a “prototype,” which dictates how a compiler will parse and interpret its invocation arguments. This is rare—see the perlsub manpage for more information.

^[†] If you wish to be powerfully tricky, read the Perl documentation about coderefs stored in private (lexical) variables.

^[‡] A warnable offense, however.