Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

  (email not shown publicly)
AOL IM: MichaelSchwern (Add Buddy, Send Message)

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Monday July 25, 2005
05:30 PM

Peeve of the moment: People who comment out old code.

[ #25883 ]

I hates nothing more than to find code like this:

# for( my $up = 1;  $up <= $height + 1;  $up++ ) {
for( my $up = 1;  $up <= $height;  $up++ ) {

It causes my eyes to do a double take. If my brain made noise it would be that *tick tick* *tick tick* *griiiIIIIiinnndd* that a hard drive makes when trying to work with a bad block. "Its code so I should be reading it but its a comment so I should be ignoring it but its code... but its a comment... and it looks just like the next line of code so its probably a bug... but its a comment... but its code... "

I've been told syntax highlighting browsers help with this, but its not a problem I want to be helped with. And I'd love to see what code looks like after a few months of this sort of style. More comment than code.

Anyhow, it reflects a fundamental lack of trust in your version control system, or a fundamental lack of a version control system. All the more amusing because I received a diff today. It contained this:

-        for( my $up = 1;  $up <= $height + 1;  $up++ ) {
+        # for( my $up = 1;  $up <= $height + 1;  $up++ ) {
+        for( my $up = 1;  $up <= $height;  $up++ ) {

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I had this exact same conversation with a coworker just a couple weeks ago. I was reviewing some changes, which included -- yes -- commenting out code.

    His argument was that the commented-out code, for a feature we were removing, would probably be needed again soon. He was expecting the feature to be re-added again. I pointed out that:

        1) Predicting the future is hard, and every time you're wrong you just clutter up the code
        2) The old code still existed in the old versions i
  • Wouldn't this:

        for( my $up = 1; $up = $height; $up++ ) {

    be more easily read if it were written as:

        for my $up (1 .. $height) {

    • No, because $height can change inside the loop. The code is from Sub::Uplevel. There's an explainatory comment and everything.
  • ACK.

    I do this a lot, temporarily, when I’m hunting bugs or when I just want to try something else. But as soon as I’ve decided which version I need, the commented crap goes out the window.

    What I find particularly jarring is finding entire sections of code or complete routines commented out in someone else’s source. It doesn’t particularly inspire trust in the codebase to see that someone is littering it with his failed experiments…

  • (this is in C, of course)

    I have a co-worker who always changes the code that he fixes by wrapping it in #ifdef tags, like

    #ifdef _BUGS_
      ...old broken code
    #else working code

    This drives me crazy, but he won't change, and no one here with authority wants to enforce anything against, this, so I just take them out when I get a chance to work on the affected files.
    • That's simple. Just go in to the standard Makefile for your build, and add -D_BUGS_.

      It'll drive him nuts for hours.

      • Randal L. Schwartz
      • Stonehenge
  • We use an IDE with code-folding. People here often comment out the top level line for a block (which automatically comments out the whole block), copy it, and make a minor change somewhere in the block (or move the block to a different library file), and then leave behind the old code in the commented out block. There are thousands of lines of commented out blocks. I wrote a crufty-comment remover in perl which removes any commented out blocks of 100 lines or more, which in some of the larger libraries save
  • I take two steps when taking over some legacy code:
    1. Delete all the comments
    2. Normalize the formatting, including vertical whitespace

    It works well enough when you're starting out on an existing codebase. At the end of the day, 3-year old (and incomplete) edit histories aren't that important, and commentary on why something changed into its current state is useless, because you're not likely to see the conditions that triggered the change way back when.

    Additionally, focusing on just the code helps you fo

  • Commented-out code is one of the things that my fluff [] program warns on.