Slashdot Mirror

← Back to Stories (view on slashdot.org)

What Are the Unwritten Rules of Deleting Code?

Posted by samzenpus on from the best-practices dept.

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?"

13 of 384 comments (clear)

  1. The more..... by phantomfive · · Score: 5, Insightful

    The more you can delete, the better.

    --
    "First they came for the slanderers and i said nothing."
    1. Re:The more..... by wmac1 · · Score: 5, Insightful

      I comment the code and leave it there for at least one minor version. If things are all right, I'll remove them. The code is in source control anyway.

    2. Re:The more..... by mwvdlee · · Score: 5, Insightful

      Why not just delete it right away? Commenting out code in version control just creates more changes.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    3. Re:The more..... by Marxdot · · Score: 5, Insightful

      "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" --Antoine de Saint Exupéry

      That is the only rule of deleting code; if you can take it away or do it more simply without causing Bad Things, do it.

    4. Re:The more..... by Anonymous Coward · · Score: 5, Insightful

      If everyone uses the system "comment out first, remove after it has shown to work", seeing commented out code means that the code is still being reviewed. That might be valuable information.

    5. Re:The more..... by tknd · · Score: 5, Insightful

      If you're going to do this, YOU HAD BETTER COMMENT ON WHY YOU COMMENTED IT OUT. Too often I come across a block of code that is just commented out. A quick glance means it had a purpose, but for what reason, I'm not sure because apparently it isn't needed anymore. So then I ask "why?" But there is no answer to this question. This is possibly the worst feeling of working with code--the idea that something was there, now is not, but they left it in for some reason and you don't know why.

      Now you're left with a couple scenarios:

      • The code caused a bug, but had some sort of purpose.
      • The code was replaced, and the new implementation is experimental which leads to
        • Exactly which lines of code did it replace?
      • It is dead code

      It is like walking into an offline factory line. Most bystanders will simply think "I had better not touch this or it could cause serious problems" so the only people in full control was the last shift of factory workers for that line. Meanwhile similar lines are still operating so you're not exactly sure why this particular production line was halted.

      Meanwhile if the code was in version control, I get a much clearer picture from diff on what exactly changed. If you just comment out a giant block and leave it there, check it in, then diff shows me that 2 lines had a comment added (in the case of block comments) or all the lines are commented out (modified, for single line comments). Now I have to diff again and skip to the version before that to get the picture I want, but now I may see other changes that may not be relevant.

      Either way, if you are commenting out code for the first two scenarios I listed, you need to think again about your version control system and manage it better. Experimental or untested stuff should be branched, not visible to other devs otherwise people make mistake it for production code. If I see commented out code blocks, I'm simply going to delete them myself because I can't read your mind and never will be able to.

    6. Re:The more..... by Anonymous Coward · · Score: 5, Insightful

      I comment the code and leave it there for at least one minor version. If things are all right, I'll remove them. The code is in source control anyway.

      That's a fine sentiment for a one-man dev team with a relatively small codebase, where you know what you're doing and can keep a handle on things, but for larger teams, people who leave commented-out code in place are annoying for everyone else.

      As you said already, it's in source control anyway, so why bother leaving it there even for one version?

      The counter arguments are that it causes additional diffs and commits that are unnecessary, and it gets in the way for other developers -- it harms readability.

      And very often, despite best intentions, it ends up being left there for a lot longer than was needed. The original developer may not come back to that file for some time, and after just a few revisions, no-one is quite sure which bits of commented out code should be deleted and which should be left in place. Or maybe even maintained -- after all, if it's been left in place, that implies it might have to be re-instated, so if the code around it changes, the commented out code really ought to also be tweaked to keep it in line.

      No-one has time to stop and figure it out either; the temptation is always just to leave it well alone -- if it's been left there, then there must have been a reason, but it's not my problem, so I won't touch it. End result, a year or two down the line, and we have huge quantities of dead code floating around, which probably wouldn't work anyway even if it was re-instated, and someone has to waste time with an excersise to go through the codebase and remove it all.

      In your world of your own little projects, keeping dead code floating around may sound like a good idea, but in the real world it really isn't.

  2. Re:Your VCS should manage this by myurr · · Score: 5, Insightful

    Revision control is just one aspect. If you aren't the only person working on the code, or if there are other external dependencies such as you publish an API that others depend upon, then some form of automated testing will help ensure you haven't broken anything by deleting that code. Heck even if you are the sole developer then automated tests are still an incredibly good thingl.

    If you are deleting code within a larger project then try deprecating the code first. Flag it as deprecated in the documentation (you do have documentation don't you?) and put log messages in the code that warn whenever it is called. After a while you can be confident that it is unused (or only used in obscure rarely called functions) and you can delete with confidence.

    Revision control is your safety net, your last line of defence if you erroneously delete code that is in fact needed. It also allows you to always refer back to that code. Good commit messages will also help.

  3. Re:How can ... by hobarrera · · Score: 5, Insightful

    Indeed, version control is the only real solution.
    We use git at work, and some coworkers insist on "commenting out" code that's no longer needed. I insist that we should delete it. Should we ever need it again, we have version control; and with proper commit messages, old code is easier to find too.

  4. Re:How can ... by SerpentMage · · Score: 5, Insightful

    No I feel you should comment it out for one version, or one iteration.

    The problem with deleting code is that you lose functionality and information. Yes yes we have this ideal world where unit tests will ensure that the code only does what it is supposed to. Be that as it may, there is a reason...

    Code that needs to be completely rewritten is crap code. We can argue how it came to be, but the reality is that every developer for one reason or another has created crap code. It is unavoidable. Crap code is code that does many things, but quite a bit of it incorrectly. It also is hard to get a grip on because of its complexity. For if it was easy to understand and easy to fix it would not require a rewrite, no?

    Thus when you rewrite you are trying to simplify, and restructure. And because you don't have a handle of the original code you are going to introduce bugs in the new code. These bugs are new cases that you have not thought about and thus need thinking about. They are not critical bugs since the rewritten code is easy to understand and easy to fix. BUT these bugs need to be cross referenced with the original code. You need to see if these bugs are bugs, or actually the correct answer. Sometimes I was working on code and thought, "crap, the new code is right even though I thought this was a bug."

    If you delete, and need to check it with version control you are adding time, effort and complexity of actions. And then instead of going back to do a cross reference you are going to introduce new bugs that can grow into weeds and cause this cycle of rewriting again.

    I have found that often when I rewrite I learn new facets of my code and figure out the critical bugs. It is then I decide to stop the rewrite, and integrate the new code into the old code and fix things up. For the I see in the rewrite that the new rewritten code is going to introduce quite a bit of new code that is going to mean retesting, and assurance that things all work. And maybe this new rewritten code will not be better after all. Deleting the old code means me merging the refactored code, with the old code introducing even more complexity.

    Commenting out is ugly, but it has made it easier to experimenting in a short order of time without causing version control havoc.

    --

    "You can't make a race horse of a pig"
    "No," said Samuel, "but you can make very fast pig"
  5. Re:That's what I do too, by bfandreas · · Score: 5, Insightful

    Well, I am management. And I prefer to actually deal with stuff.
    If the timeframe is borked, then I need to know so I can talk to the client about cutting features, postponing release, release in stages, etc. There is a lot you can do. But shoving out stuff that doesn't work or is unrelyable is something that will never be properly resolved.
    If you desperately try to meet the release date and you actually somewhat succeed, then the books are closed on that release. But if you spend a lot of time after the release on bug fixing then eyebrows will be raised and your competence as a developer will be questioned. It's not your job to make management happy. It's management's job to make your job possible.

    On unrelated news: Overtime is a clear indicator of management failure. Also massive overtime to meet deadlines never work and is never worth the effort. Been doing this for 15 years and I yet have to encounter one instance where this actually proved to do more good than harm.

    --
    20 minutes into the future
  6. Re:How can ... by ixnaay · · Score: 5, Insightful

    I need a moderation option for 'good points, but excessive dickishness' Anyways, I do pretty much exactly the same as you do; although in the firmware world.

  7. Re:How can ... by Lumpy · · Score: 5, Insightful

    "Code that needs to be completely rewritten is crap code. We can argue how it came to be, but the reality is that every developer for one reason or another has created crap code. It is unavoidable."

    I have found this to be the case for all code that comes out of TI for their MSP430 embedded processors. They use a convoluted system for their code that only a nutjob would love. I have thrown out their drivers for interfaces and rewrote them by hand just to avoid their crap. You DO NOT declare a function for your device driver in the .h file of another driver. WTF is wrong with their programmers?

    --
    Do not look at laser with remaining good eye.