In my book, it is a sin to comment out blocks of code by any of

• #ifdef ... #endif or /* ... */
• =foo ... =cut
• if ( false ) { ... }

Doing any of these can make maintenance a living hell. It becomes difficult to tell live code from dead, and grep (or equivalent) become an unreliable way to tell where a variable is referenced, or where a method is called.

I'm O.K., though, with commenting out blocks of code via any of

• //
• #

in the left margin, as long as there's a left-justified comment explaining why why the code has been commented out. (This causes the comment to stick out like a sore thumb, but that's the point. It's got to be immediately evident to whoever is reading the code.)

Since commented-out blocks of code represent issues that need to be resolved, I've adopted the practice of using a special comment "tag" that's easy to extract mechanically (via, surprise, a Perl script!) so that we can generate reports of where our code issues are during development or maintenance. These tags look like:

  #TBD(dws) version 2.0 of mummble breaks if you do this
  #      $mummble->do_this();
[download]

The goal is to drive issues to zero at release, but sometimes timeboxes don't permit that. And lack of time is no excuse to lose track of where your issues are.