Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

What Are the Unwritten Rules of Deleting Code? 384 384

Press2ToContinue writes "I came across this page that asks the question, 'what are the unwritten rules of deleting code?' It made me realize that I have seen no references to generally-accepted best-practice documents regarding code modification, deletion, or rewrites. I would imagine Slashdot's have come across them if they exist. The answers may be somewhat language-dependent, but what best practices do Slashdot's use when they modify production code?"
This discussion has been archived. No new comments can be posted.

What Are the Unwritten Rules of Deleting Code?

Comments Filter:
  • Re:Revertable (Score:5, Interesting)

    by gagol (583737) on Monday January 07, 2013 @03:13AM (#42502027)
    When in doubt, comment out and document. I also like to keep a commented (disabled by comments) generic version of a function if I have to work a heavily optimised version. For future generations, and keep sanity when code is revisited.
  • Re:The more..... (Score:5, Interesting)

    by Pieroxy (222434) on Monday January 07, 2013 @04:46AM (#42502521) Homepage

    Once it's not in the file anymore it's out of your attention span. Leaving the code there for a revision or two allow anyone looking into the file to be instantly aware that something has happened very recently, which is usually what the person is looking for.

    Depending on your language, putting a "TODO" marker allows for easy and quick cleanup afterwards.

  • Re:The rules (Score:4, Interesting)

    by iapetus (24050) on Monday January 07, 2013 @05:59AM (#42502883) Homepage

    1. Not always true by a long way, especially when you're coding for devices with limited space. It can also lead to unnecessary duplication, overly convoluted logic to avoid modifying existing code, unnecessary duplication, poor performance and unnecessary duplication.

    2. Bug fixes are dangerous? Really? That could have saved me a lot of time at my job before last. :D

    3. If you think deleting code causes information to be lost, you need to review your source code control policies. Now. Yes, it can be dangerous to remove crufty looking old code, because it frequently contains years worth of minor fixes to deal with bizarre edge cases, device oddities and the suchlike. But you know what? Those should all be well commented in the code, and covered by appropriate tests that will ensure your new version works too. If they're not, you might need to review some other policies as well.

  • Re:How can ... (Score:3, Interesting)

    by Alain Williams (2972) <> on Monday January 07, 2013 @07:22AM (#42503257) Homepage


    Leave a comment saying something like: Version XX removed code to do YY because ZZ. The important things to comment are not what the code is doing (although that is useful) but the reasons for doing things and even more importantly the reasons for NOT doing things (eg: tried it but it was too slow).

    Comments are an apparently obscure feature of every programming language. I say obscure as most of the code that I see uses it rarely except for a copyright block.

  • Re: How can ... (Score:2, Interesting)

    by minogully (1855264) on Monday January 07, 2013 @09:22AM (#42503853) Journal
    A colleague of mine comments everything and deletes nothing despite the fact that we use version control. This leaves the actual non-commented code difficult to read and understand. Also, there have been times I may need to uncomment the code to use it again, but it takes too long to readapt it to work with the surrounding code that has evolved since the commenting, let along to understand exactly what's going on to make sure there aren't bugs. For me, I think deleting commented code should be based on the following algorithm: x = the amount of time to understand and/or adapt commented code for reintroduction y = the amount of time to rewrite the same piece of code if (x > y) { Delete the code } else { Leave it }

After an instrument has been assembled, extra components will be found on the bench.