Always unpack @_ first.

Subroutines always receive their arguments in the @_ array. But accessing them via $_[0], $_[1], etc. directly is almost always a Very Bad Idea. For a start, it makes the code far less self-documenting:

  Readonly my $SPACE => q{ };

  # Pad a string with whitespace...
  sub padded {
      # Compute the left and right indents required...
      my $gap   = $_[1] - length $_[0] ;
      my $left  = $_[2] ? int($gap/2) : 0;
      my $right = $gap - $left;

      # Insert that many spaces fore and aft...
      return $SPACE x $left
           . $_[0]
           . $SPACE x $right;
  }

Using “numbered parameters” like this makes it difficult to determine what each argument is used for, whether they’re being used in the correct order, and whether the computation they’re used in is algorithmically sane. Compare the previous ver sion to this one:

  sub padded {
      my ($text, $cols_count, $want_centering) = @_;

      # Compute the left and right indents required...
      my $gap   = $cols_count - length $text;
      my $left  = $want_centering ? int($gap/2) : 0;
      my $right = $gap - $left;

      # Insert that many spaces fore and aft...
      return $SPACE x $left
           . $text
           . $SPACE x $right;
  }

Here the first line unpacks the argument array to give each parameter a sensible name. In the process, that assignment also documents the expected order and intended purpose of each parameter. The sensible parameter names also make it easier to verify that the computation of $left and $right is correct.

A mistake when using numbered parameters:

  my $gap   = $_[1] - length $_[2] ;
  my $left  = $_[0] ? int($gap/2) : 0;
  my $right = $gap - $left;

is much harder to identify than when named variables are in the wrong places:

  my $gap   = $cols_count - length $want_centering;
  my $left  = $text ? int($gap/2) : 0;
  my $right = $gap - $left;

Moreover, it’s easy to forget that each element of @_ is an alias for the original argument; that changing $_[0] changes the variable containing that argument:

  # Trim some text and put a "box" around it...
  sub boxed {
      $_[0] =~ s{\A \s+ | \s+ \z}{}gxms;
      return "[$_[0]]";
  }

Unpacking the argument list creates a copy, so it’s far less likely that the original arguments will be inadvertently modified:

      $text =~ s{\A \s+ | \s+ \z}{}gxms;
      return "[$text]";
  }

It’s acceptable to unpack the argument list using a single list assignment as the first line of the subroutine:

  sub padded {
      my ($text, $cols_count, $want_centering) = @_;

      # [Use parameters here, as before]
  }

Alternatively, you can use a series of separate shift calls as the subroutine’s first “paragraph”:

  sub padded {
      my $text           = shift;
      my $cols_count     = shift;
      my $want_centering = shift;

      # [Use parameters here, as before]
  }

The list-assignment version is more concise, and it keeps the parameters together in a horizontal list, which enhances readability, provided that the number of parameters is small.

The shift -based version is preferable, though, whenever one or more arguments has to be sanity-checked or needs to be documented with a trailing comment:

  sub padded {
      my $text           = _check_non_empty(shift);
      my $cols_count     = _limit_to_positive(shift);
      my $want_centering = shift;

      # [Use parameters here, as before]
  }

Note the use of utility subroutines (see “Utility Subroutines” in Chapter 3) to perform the necessary argument verification and adjustment. Each such subroutine acts like a filter: it expects a single argument, checks it, and returns the argument value if the test succeeds. If the test fails, the verification subroutine may either return a default value instead, or call croak() to throw an exception (see Chapter 13). Because of that second possibility, verification subroutines should be defined in the same package as the subroutines whose arguments they are checking.

This approach to argument verification produces very readable code, and scales well as the tests become more onerous. But it may be too expensive to use within small, frequently called subroutines, in which case the arguments should be unpacked in a list assignment and then tested directly:

  sub padded {
      my ($text, $cols_count, $want_centering) = @_;
      croak  q{Can't pad undefined text}    if !defined $text;
      croak qq{Can't pad to $cols_count columns} if $cols_count <= 0;

      # [Use parameters here, as before]
  }

The only circumstances in which leaving a subroutine’s arguments in @_ is appropriate is when the subroutine:

• Is short and simple
  
• Clearly doesn’t modify its arguments in any way
  
• Only refers to its arguments collectively (i.e., doesn’t index @_ )
  
• Refers to @_ only a small number of times (preferably once) 
  
• Needs to be efficient

This is usually the case only in “wrapper” subroutines:

  # Implement the Perl 6 print+newline function...
  sub say {
      return print @_, "\n";
  }

  # and later...

  say( 'Hello world!' );
  say( 'Greetings to you, people of Earth!' );

In this example, copying the contents of @_ to a lexical variable and then immediately passing those contents to print would be wasteful.