What Are the Unwritten Rules of Deleting Code?

← Back to Stories (view on slashdot.org)

What Are the Unwritten Rules of Deleting Code?

Posted by samzenpus on Sunday January 6, 2013 @07:04PM 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?"

21 of 384 comments (clear)

Min score:

Reason:

Sort:

The more..... by phantomfive · 2013-01-06 19:06 · 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 rwven · 2013-01-06 19:33 · Score: 5, Informative
  
  Yeah, I have no qualms about deleting code. There are others I've seen who just comment out massive blocks of code and leave them there....for me to eventually find and delete myself, apparently. Version control is there for a purpose. If you need something back...it's there.
2. Re:The more..... by wmac1 · 2013-01-06 19:58 · 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.
3. Re:The more..... by mwvdlee · 2013-01-06 20:14 · 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?
4. Re:The more..... by Marxdot · 2013-01-06 20:28 · 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.
5. Re:The more..... by Anonymous Coward · 2013-01-06 20:41 · 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.
6. Re:The more..... by Pieroxy · 2013-01-06 20:46 · Score: 5, Interesting
  
  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.
  
  --
  Write boring code, not shiny code!
7. Re:The more..... by tknd · 2013-01-06 22:13 · 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.
8. Re:The more..... by Anonymous Coward · 2013-01-06 22:47 · 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.
Re:How can ... by ChunderDownunder · 2013-01-06 19:10 · Score: 5, Informative

version control.
Re:Your VCS should manage this by myurr · 2013-01-06 19:29 · 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.
My rules for deleting code by EuclideanSilence · 2013-01-06 19:36 · Score: 5, Funny

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.
There used to be rules ... by inglorion_on_the_net · 2013-01-06 19:46 · Score: 5, Funny

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.

--
Please correct me if I got my facts wrong.
Re:Vigil by rwaldin · 2013-01-06 19:59 · Score: 5, Informative

Ah, Vigil! What a wonderfully amusing language...
https://github.com/munificent/vigil

But isn't a language that deletes code crazy?
No, wanting to keep code that demonstrably has bugs according to its own specifications is crazy. What good could it possibly serve? It is corrupted and must be cleansed from your codebase.
Vigil will do this for you automatically.
Vigil deleted a function. Won't that cause the functions that call it to fail?
It would seem that those functions appear to be corrupted as well. Run Vigil again and it will take care of that for you. Several invocations may be required to fully excise all bugs from your code.
This comment has been deleted ... by ElRabbit · 2013-01-06 20:32 · Score: 5, Funny

... for clarity
Re:How can ... by hobarrera · 2013-01-06 21:52 · 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.
Re:How can ... by SerpentMage · 2013-01-06 22:15 · 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"
Re:That's what I do too, by iapetus · 2013-01-06 22:51 · Score: 5, Funny

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. ;)

--
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Re:That's what I do too, by bfandreas · 2013-01-06 23:02 · 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
Re:How can ... by ixnaay · 2013-01-07 00:20 · 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.
Re:How can ... by Lumpy · 2013-01-07 01:12 · 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.