Assuming that you haven't deliberately made things worse on yourself by concealing objects, a programmer new to your code will note that you have kindly warned him that $resourceHandle is an object via the ->release just before the closing brace (this is the thing that I want the warning to check for, and you've done exactly that), and check acquire_locked_resource, get_database_handle, get_current_users, get_elapsed_time, and the output method on whatever acquire_locked_resource claims in the comments to return, and assume that you were sane enough to make the release an explicit destructor before the brace. If you did something insane like sticking an object in $count and $elapsed and hid an operator overload in '/', or hid an object in $users_per_second and then tinkered with the lvalue assignment, then committed that sub without comment, you deserve to have your access revoked.
In my stylistic opinion, of course. No personal offense or disrespect intended, especially given that this is just example code.
That said, the original topic at hand is warning messages on unused variables, and you've declared: $resourceHandle, $dbh, $count, $elapsed, and $users_per_second, and every single one of those got used. Why are you worrying about the warning on this code?
The question is why you think it is better to omit the final $resourceHandle->release particularly if $resourceHandle->output didn't exist. if your code looked like this:
a new developer might not realize that $resourceHandle was more than a simple scalar, and then go do something silly like writing a locking wrapper (you fortunately also protected against this by using a readable sub name on the first line, which I have unkindly made more obscure for the sake of example).sub foo { my $resourceHandle = locked_resource(); my $dbh = get_database_handle; my $count = get_current_users($dbh); my $elapsed = get_elapsed_time(); my $users_per_second = $count/$elapsed; print "Found ",$users_per_seond," users per second.\n"; };
I'm not arguing against the value of complex constructors and destructors in specific cases. This is entirely about
being clearer than$resourceHandle->release; };
};
If you can show me an example where omitting the final explicit destructor on an object used solely for that purpose (i.e. is not touched by any other code between its declaration and that point is either the clearest possible way to solve a problem or the only maintainable way to solve a problem, and that the situation is one that crops up often enough that having a warning on unused variables would cause more problems with people encountering this turning off warnings completely than others would gain by fixing questionable code, I might very well retract my position on this warning (though I would probably continue to use it myself unless I found myself doing a lot of whatever was causing the problem).
I can actually give you an example of this in C, which fortunately does not apply to Perl: a templated code generator was spitting out miniprograms that sometimes wanted arguments and sometimes didn't. -Wunused spat out warning messages for every component that didn't, because argc and argv wouldn't be used. Modifying the generator to tell the difference was going to be a pain, so the warning got turned off for the second stage of the build. I support that decision. I haven't so far seen an analogue in Perl. The closest so far is the 'touch' example, but I'd spend an extra twelve characters once per project to deal with it.
In reply to Re^10: Warnings on unused variables?
by AZed
in thread Warnings on unused variables?
by AZed
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |