use Perl

• Yes! (Score:1)

  by mary.poppins (3530)

  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
• for loops (Score:1)

  by mary.poppins (3530)

  Wouldn't this:
  
      for( my $up = 1; $up = $height; $up++ ) {
  
  be more easily read if it were written as:
  
      for my $up (1 .. $height) {
  
  ?
  
  • Re:for loops (Score:2)

    by schwern (1528)

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

  by Aristotle (5147)

  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…
• better than #ifdef (Score:1)

  by jdavidboyd (3251)

  (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
    ...new working code
  #endif
  
  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.
  • Re:better than #ifdef (Score:2)

    by merlyn (47)

    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
• In our non-perl code base (Score:1)

  by runrig (3385)

  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
• Just ignore it (Score:2)

  by ziggy (25)

  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
• Fluff (Score:2)

  by petdance (2468)

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

  --
  

  --
  xoa