Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

What Are the Unwritten Rules of Deleting Code? 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:
  • Vigil (Score:4, Funny)

    by Anonymous Coward on Monday January 07, 2013 @03:17AM (#42502045)

    Let Vigil delete your code for you when it's wrong and must be punished.

  • by EuclideanSilence ( 1968630 ) on Monday January 07, 2013 @03:36AM (#42502123)

    Ok so you are working on a team and deleting code. Here are some basic rules to follow.
    1) Don't delete your boss's code. Just change all the function calls to go around it. If he asks you about it, say that someone else changed it.
    2) Don't cuss out the guy who's code you are deleting until after you are done. You might have to ask him why he did certain things (unexpected library behavior etc).
    3) Make sure the code you add to replace the old code is longer than what you deleted. That way, you can tell your boss that you added 'x' lines of code to the project.
    4) Don't waste time unit testing your new code. Obviously if you have to replace the old code, then you are a better programmer than the last one. If the last programmer's code passed unit tests, and you are better, then obviously yours would pass unit tests too.
    Any politeness the other programmer shows to you after you delete his code is not to be trusted. The code we write is pride to us, and deleting someone else's code is like seeing your coworkers girlfriend naked in the shower. Sure, it's not really your fault and you didn't really do anything bad. But expect some negative passive aggressive behavior in response.

  • by inglorion_on_the_net ( 1965514 ) on Monday January 07, 2013 @03:46AM (#42502177) Homepage

    There used to be written rules for deleting code. Then someone deleted them. And since we don't use version control, we have no way to get them back.

  • by ElRabbit ( 2624627 ) on Monday January 07, 2013 @04:32AM (#42502417)
    ... for clarity
  • by Chrisq ( 894406 ) on Monday January 07, 2013 @05:18AM (#42502653)

    The more you can delete, the better.

    Starting from the Murphy's law on programming: Every non trivial program has at least one bug

    You can derive by rigorous analogy the Murphy's law on not-programming: Every non written code has exactly zero bugs

    I have it - the holy grail, the key to bug free coding. If the deleted code has no bugs just restore the deleted lines and delete the rest. You will then have bug free programs.

  • by iapetus ( 24050 ) on Monday January 07, 2013 @06:51AM (#42503129) Homepage

    Unfortunately bitter experience prevents me from being too nasty on this one, because too many times I've been through the process of having good test policies in place, followed by senior management decreeing that in order to meet deadlines, testing and documentation will have to fall by the wayside 'just for a few weeks'. I know it would count as justifiable homicide, but I still can't afford the court time. ;)

  • by Anonymous Coward on Monday January 07, 2013 @07:44AM (#42503339)

    i never delete code even with version control, i just comment it out so that others can easily see what i removed with a comment as to why.

  • by swillden ( 191260 ) <shawn-ds@willden.org> on Monday January 07, 2013 @12:01PM (#42505565) Journal

    You can switch branches in SVN just fine.

    And as a bonus you'll have time to go get a cup of coffee!

For God's sake, stop researching for a while and begin to think!

Working...