With well-written code, comments (which I consider seperate from the overall documentation, e.g. POD) are often unnecessary. For instance, probably all the CGIs I've written over the past year have a set_params() sub that (surprise!) takes in the CGI input params. It is almost always simply some form of:

use CGI qw(:standard);

sub set_params
{
   my %fields;
   $fields{foo} = param('foo') || 0;
   $fields{bar} = param('bar') || 0;
   $fields{baz} = param('baz') || 0;

   return %fields;
}
[download]

I used to mix in some validation, but I'm trying to force myself to do that in a seperate sub.

A maintenance programmer looking at the above can know exactly what parameters are being input. No comments necessary. Occasionally, there are some hoops to jump through, in which case a sprinkling of comments is needed.

POD, IMHO, is for telling what the overall program/module does. Which is why I don't really like the =for comment method of multi-line comments.

Having a boatload of comments is a good indicator of poor code. Hint: if I have to run your code through B::Deparse just to get rid of your comments and save my sanity, your code probably sucks. Those thousand-dollar "source code obfuscation" tools have got it all wrong--leaving massive numbers of comments in place is a great way to protect your source code :)

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated