in reply to Re^3: Warnings on unused variables?
in thread Warnings on unused variables?

For example:

sub foo1 {
  my ($c, $d, $e, $f) = @_;
  return $d * f;
}

sub foo2 {
  my ($c, $d, $e, $f) = @_;
  return $c + $d + $e + $f;
}

sub do_foo {
  my $which = $_[0] ? \&foo1, \&foo2;
  $which->(1, 2, 3, 4);
}

[download]

As you see foo1 uses only uses the second argument and fourth ($d, $f). But the assignment happens via my ($c, $d, $e, $f) = @_;. If a warnings is introduced for lexical variables that are used once then it will warn. (lexicals $c and $e are declared and initialized but never used.

Yes, the assignment could be changed into: my ($d, $f) = @_[1, 3]; but this would be worse from a maintenance point of view.

With my ($c, $d, $e, $f) = @_; you know exactly what parameters are passed (assuming they get a decent name). If you use my ($d, $f) = @_[1, 3]; then you are clueless about the other arguments.
If you later need the other arguments then you need to start looking in what order they were passed.

Replies are listed 'Best First'.
Re^5: Warnings on unused variables?
by AZed (Monk) on Oct 02, 2008 at 01:18 UTC

    What I'm not seeing is why you would think that $c or $e could have a name better than undef. 

    sub foo1 {
    my (undef, $d, undef, $f) = @_;
    return $d * $f;
}

    [download]
    ... works just fine, produces no warnings, and has the added advantage of immediately giving the parameter a name that makes it absolutely clear that the value will be discarded.
[reply]
[d/l]
[select]

      Because it is easier for maintenance to name them from the beggining.

      Suppose you use my (undef, $d, undef, $f) = @_; and 2 months later you also need another variable. Then you need to go look to what code calls is then try to add the argument there - or find another way of passing it - and ultimetly find out it is already being passed as the 3th argument.

      A real live example is from a mod_perl framework that uses: my ($data, $p, $r, $dbh) = @_;.
      The explenation of the variables:

      • $data: The object of a data class that is linked with the module,
      • $p: A list of common arguments (who is logged in, what language, what level, ...),
      • $r: The Apache::Request object,
      • $dbh: The database connection,


      While most of the code will never use $r and $dbh it is still useful to store them in a lexical since it is immposible to predict how the subroutine will grow and when it will need them.

      What you call an advantage I call a serious disadvantage for maintenance. If you later need $r for some reason you need to look up as which argument it is passed.

[reply]
[d/l]
[select]
        Because it is easier for maintenance to name them from the beggining.

        In my opinion, it's easier for maintenance to not have positional arguments if you have more than two arguments.

        I would write that as: 

        sub whatever {
    my %argument = @_;
    my $data = $argument{data};
    my $p = $argument{p};
    my $r = $argument{r};
    my $dbh = $argument{dbh};
    ...
}
whatever dbh => $dbh, data => "...", p => "...", r => "...";

        [download]
        Except that I wouldn't use names like 'p', 'r', and certainly not 'data'.
[reply]
[d/l]

        Ah, that's a useful example, thanks.

        Update: now that it's been sitting in the back of my head for a while, however, I think I'd always immediately undefine the unused variables after acquiring them anyway, to make it clear at the top of the subroutine that it doesn't implement anything that uses those arguments. That would still clear the warning. The only time this is probably a bad idea is when a lot of arguments are being passed but not used — but then you should arguably be passing an object or hashref.

[reply]

In Section Seekers of Perl Wisdom