Re^6: Warnings on unused variables?

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.

Comment on Re^6: Warnings on unused variables? Select or Download Code

Replies are listed 'Best First'.
Re^7: Warnings on unused variables? by JavaFan (Canon) on Oct 02, 2008 at 16:15 UTC
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]
Re^7: Warnings on unused variables? by AZed (Monk) on Oct 02, 2008 at 16:00 UTC
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]