Re^10: Warnings on unused variables?

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:

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";
};
[download]

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).

I'm not arguing against the value of complex constructors and destructors in specific cases. This is entirely about

  $resourceHandle->release;
};
[download]

being clearer than

};
[download]

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.

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

Replies are listed 'Best First'.
Re^11: Warnings on unused variables? by Tanktalus (Canon) on Sep 28, 2008 at 02:53 UTC
I have to entirely disagree with you here. I like set-and-forget semantics. (I'm actually concerned about mark-and-sweep garbage collection in Perl 6 going toward's Java's non-guarantee of destructor calls, though I don't really know where Perl 6 stands on it.) It means that the compiler will generate code that properly handles resource reclamation, whether that's releasing a database connection (and rolling back any transactions currently underway), or deleting a temporary file (talk about security holes!), or decrementing a lock counter (possibly freeing it). It means that I can't forget to do the cleanup. And I forget a lot. Missing a "release" on a lock, for example, can lead to deadlock. Missing database connection releases can result in wasted server resources in tracking unfinished transactions, possibly reducing responsiveness on the server. Failing to delete temporary files can result in disk space consumption, often on partitions that are among the smallest partitions on the box if on unix, possibly exposing old data to users that shouldn't see it (though leaving it open to other users for any length of time is bad, but auto-delete can reduce the scope of the vulnerability). These can be catastrophic errors. Manually freeing resources that can be freed automatically is just asking for problems. Letting the compiler do it for you is Lazy - in the right way.	[reply]
Re^12: Warnings on unused variables? by AZed (Monk) on Sep 28, 2008 at 06:24 UTC
I think you misunderstand me. I also like set-and-forget semantics... at least to function. I would be very unhappy if Perl stopped doing cleanup as scope exited and my screwups resulted in instant malfunctions rather than warnings. I just like to be gently thwapped with a wet noodle when I forget something obvious enough that a compiler can spot it. But I want the language to be only my fallback, because if I stop trying to outperform the automated cleanup, if I stop trying to make sure that I will always, always be able to figure out what I was doing in a chunk of code a year after not looking at it, eventually I am going to come back to code only held together by the automated cleanup and make a mistake too subtle for either me or the compiler to notice. And if I pass that code onto someone else, some year I'm going to download an updated version where someone else made a subtle mistake, or had to rewrite a chunk of it, and wonder if it was my fault. And that's why I want to be able to get warnings on "stylistic" issues. I keep looking for ways to turn on extra warnings without slowing down my main work too much. A lot of what I want can be implemented in subsequent unit tests (and in fact one of the first things I did on my recent project was set up a sample input with a lot of weird things wrong with it and run my code against every time I made a change), but one of the major strengths of a scripting language over a compiled language is the instant feedback from when you did something wrong. I like that. I know there's a culture clash thing going on here, and my approach probably comes off as plodding, paranoid, and clunky to people who have taken code golf and functional programming to a fine art form, but I like to think that one of the things that we can agree on is that (at least as of a week or so ago, when 0.02 of warnings::unused showed up), Perl allows a wide enough range of expression to work for both of us.	[reply]
Re^13: Warnings on unused variables? by SuicideJunkie (Vicar) on Sep 29, 2008 at 17:35 UTC
"stylistic" issues That's the key here, I think. Strictures and Warnings are for things that will break the functionality of your code. If you get a warning, your code probably will not work. Stylistic issues mean that your code works just fine, but somebody thinks it looks ugly. Other people think it looks better. Personal opinions... which is why such things should stay separate from strict/warn, and stay in things like Perl::Critic	[reply]
Re^11: Warnings on unused variables? by ikegami (Patriarch) on Sep 28, 2008 at 00:35 UTC
This is entirely about "`$resourceHandle->release; };`" being clearer than "`};`" {Warnings to enforce style}--	[reply] [d/l] [select]
Re^12: Warnings on unused variables? by AZed (Monk) on Sep 28, 2008 at 00:48 UTC
Okay, that's a fair philosophical position to take, but it's a difference we probably can't resolve by discussion.	[reply]
Re^11: Warnings on unused variables? by Corion (Patriarch) on Sep 28, 2008 at 08:25 UTC
My example is not about "omitting the final explicit destructor", it's about forgetting the final explicit destructor. That code block can die in at least two places (`$dbh` set to `RaiseError`, or `$elapsed` being zero) and then never call the destructor, leading to memory leaks and/or unreleased locks. Creating the lock-release right at lock acquisition prevents such oversights, and having to disable each and every such instance is foolish.	[reply] [d/l] [select]