Home arrow Perl Programming arrow Page 4 - Subroutines in Perl

Named Arguments - Perl

Subroutines let programmers extend the Perl language...at least in theory. There are certain pitfalls for which you need to be alert. This article, the first of three parts, will warn you about those pitfalls and help you avoid them. It is excerpted from chapter nine of the book Perl Best Practices, written by Damian Conway (O'Reilly; ISBN: 0596001738). Copyright © 2006 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

TABLE OF CONTENTS:
  1. Subroutines in Perl
  2. Homonyms
  3. Argument Lists
  4. Named Arguments
By: O'Reilly Media
Rating: starstarstarstarstar / 10
August 16, 2007

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement


Use a hash of named arguments for any subroutine that has more than three parameters.


Better still, use named arguments for any subroutine that is ever likely to have more than three parameters.

Named arguments replace the need to remember an ordering (which humans are comparatively poor at) with the need to remember names (which humans are relatively good at). Names are especially advantageous when a subroutine has many optional arguments—such as flags or configuration switches—only a few of which may be needed for any particular invocation.

Named arguments should always be passed to a subroutine inside a single hash, like so:

  sub padded {
      my ($arg_ref) = @_;

      my $gap   = $arg_ref->{cols} - length $arg_ref->{text};
     
my $left  = $arg_ref->{centered} ? int($gap/2) : 0;
     
my $right = $gap - $left;

      return $arg_ref->{filler} x $left
            
. $arg_ref->{text}
            
. $arg_ref->{filler} x $right;
  }

  # and then...
 
for my $line (@lines) {
     
$line = padded({ text=>$line, cols=>20, centered=>1, filler=>$SPACE });
  }

As tempting as it may be, don’t pass them as a list of raw name/value pairs:

  sub padded {
      my %arg = @_;

      my $gap   = $arg{cols} - length $arg{text};
     
my $left  = $arg{centered} ? int($gap/2) : 0;
     
my $right = $gap - $left;

      return $arg{filler} x $left
            
. $arg{text}
            
. $arg{filler} x $right;
  }

  # and then...
 
for my $line (@lines) {
     
$line = padded( text=>$line, cols=>20, centered=>1, filler=>$SPACE );
  }

Requiring the named arguments to be specified inside a hash ensures that any mismatch, such as:

  $line = padded({text=>$line, cols=>20..21, centered=>1, filler=>$SPACE});

will be reported (usually at compile time) in the caller’s context:

  Odd number of elements in anonymous hash at demo.pl line 42

Passing those arguments as raw pairs:

  $line = padded(text=>$line, cols=>20..21, centered=>1, filler=>$SPACE);

would cause the exception to be thrown at run time, and from the line inside the subroutine where the odd number of arguments were unpacked and assigned to a hash:

  Odd number of elements in hash assignment at Text/Manip.pm line 1876

It is okay to mix positional and named arguments, if there are always one or two main arguments to the subroutine (e.g., the string thatpadded()is supposed to pad) and the remaining arguments are merely configuration options of some kind. In any case, when there are both positional arguments and named options, the unnamed positionals should come first, followed by a single reference to a hash containing the named options. For example:

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

      my $gap   = $arg_ref->{cols} - length $text;
     
my $left  = $arg_ref->{centered} ? int($gap/2) : 0;
     
my $right = $gap - $left;

      return $arg_ref->{filler} x $left . $text . $arg_ref->{filler} x $right;
  }

  # and then...
 
for my $line (@lines) {
     
$line = padded( $line, {cols=>20, centered=>1, filler=>$SPACE} );
  }

Note that using this approach also has a slight advantage in maintainability: it sets the options more clearly apart from the main positional argument.

By the way, you or your team might feel that three is not the most appropriate threshold for deciding to use named arguments, but try to avoid significantly larger values of “three”. Most of the advantages of named arguments will be lost if you still have to plough through five or six positional arguments first.

Please check back next week for the continuation of this article. 



 
 
>>> More Perl Programming Articles          >>> More By O'Reilly Media
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PERL PROGRAMMING ARTICLES

- Perl Turns 25
- Lists and Arguments in Perl
- Variables and Arguments in Perl
- Understanding Scope and Packages in Perl
- Arguments and Return Values in Perl
- Invoking Perl Subroutines and Functions
- Subroutines and Functions in Perl
- Perl Basics: Writing and Debugging Programs
- Structure and Statements in Perl
- First Steps in Perl
- Completing Regular Expression Basics
- Modifiers, Boundaries, and Regular Expressio...
- Quantifiers and Other Regular Expression Bas...
- Parsing and Regular Expression Basics
- Hash Functions

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: