One of the advices for what and when to refactor was that any time you feel the need to comment a block of code, to explain what it does, it was time to extract that piece of code into a subroutine and give it a good name. That way it would be obvious what happened at that place by reading the name of the sub, and the need for the comment disappear.

That also would apply here - as soon - or as long - as you (would) need a comment to explain what a variable is for, you should rename it to describe what it holds. This is essentially what you say above, of course - just thought it would be a (perhaps) good "rule of thumb" to keep in mind.

This still means that using for instance $i as an iterator variable in a for loop probably doesn't need any comment, and thus it doesn't need to be renamed either.

As many others have said, apart from one-liners and the like, I do try to name my variables in a readable fashion - matter of factly, my variable names are often quite verbose even in test scripts, because the extra typing does save time and pain even during the short time the test script lives. Otherwise I tend to resort to $_ and friends for Q&D coding. :) Noticable execptions include for instance my habit to name the CGI object $q, but that is kind of a convention, so I don't feel too bad about it. I do name the different Parser objects (like HTML::TokeParser) $parser etc, instead of simply $p.