It turns into a hellbound rathole if you take that too far though. I use a compromise approach, which is to try to make at least the variables self-explanatory where necessary, then when the routine is built and ready for the testing phase, I ask myself what additional information a maintainer (in addition of course to the mandatory change log) might need and add in comments in a single after-pass. In such cases, avoiding comments by forcing the code to be self-explanatory would also require sordid travesties of the language to be inflicted upon it. Although, when I was a total newbie and hadn't yet learned about strict references, I didn't realise back then just how horrible it actually was to do things like <travesty>:
{ no strict; return _xyz_must_have_failed_; }
</travesty>
instead of simply
return 0; # xyz must have failed