Personally, I think your code should make sense by itself, first and foremost. Name your variables, subroutines, packages, etc.. with descriptive terms. Use a name like get_current_standing() for a sub instead of standing()

If I develop close with another coder, nothing ticks me off more then shortcuts like these. Then the errors come in .. you track it down to a file named "sup_off.pl" that has no record of who made it, is a year old, and the whole namespace is a shortcut. Save the greek for hex! (Sorry.. venting.).

As for myself i sprinkle #TODOs and i work the pod as i go.. I keep stuff in cvs too... That's a million zillion times more important then commenting subroutines! Jeez, this doesn't sound like a perl oriented environment at all.. sounds more like javascript to me. Comments don't spit on perldoc, you know? Users and even the developers should not have to open the code to know how to use it.. but I'm just being a parrot here. But.. the parrot talk makes sense to me.

I think you want to do what is best- Not just what the goons tell you to do. So.. get a copy of Perl Best Practices, it will kick you in the nuts.. but it will also give you discipline and inspiration. Lastly.. IMHO, look at cpan modules, look at their documentation.. where are the comments there? I don't think pod will take much longer to write then ##.. besides.. You can use perldoc on any files with pod and you get nice formatted code on the screen. Leaves out the comments.