Fog Creek Software
Discussion Board

How often do you delete code?

I am currently going through a whole lot of code which dates back to 1999, and has been much ammended over many iterations of bug-fixing.  And a lot of that code is redundant and dead.  I mean - there are sections which have four levels of commenting out (I ought to mention that this is a VB application).  I can't take it any more - it is so ... messy.  The temptation is to strip out all that stuff, effectively giving the code a good lufer-type scrubbing, peeling off all that nasty crusty epidermis, to reveal glowing pink ASCII (no, I don't really have my IDE set up that way).  And that is before doing actual analysis on how to remove functional redundant stuff.

Of course, what stops us from doing this is simply one thing: fear of screwing up working code.  I mean, you might just - just need that section to deal with memory problems with ActiveX Documents in IE 3.0 again.

Personally, as long as you make careful use of code tools, and use Source control, there should be no problems.  So - how often in the software cycle do you actually delete code?

Mark Alexander Bertenshaw
Tuesday, May 21, 2002

I must confess I don't usually throw out already out-commented code as well.
It's easy to rationalize that we are not throwing that useless clutter out in fear we might overlook that single statement not commented out in the midst of all the comments.
But it really comes down to that "never touch a running system" feeling deep down. It all reminds me of that famous "magic-more magic" switch story (
Always keep your code in the "more magic" position or get out those wire cutters. :-)

Claus Christensen
Tuesday, May 21, 2002

Great story that magic one!

Matthew Lock
Tuesday, May 21, 2002

I've always felt that cleaning up the code is important.  I like to comment it out and date it.  If I can see that it's been commented out for a few months and it hasn't had any problems, I'll delete it for good.

Of course, a good source control system is important.  However, even if I didn't have it, I would still clean up the code.

Matt Woodworth
Tuesday, May 21, 2002

I do the same as Matt - that is, comment (or #ifdef) things out with a date/version tag, and then after a while if it's still unused, delete it. However, I _always_ leave a comment in the file (usually at the top of the file, unless the deleted section is in the middle of a routine) what was the function of the deleted code.

Even though the revision control system maintains old copies, people don't review it unless they know what they're looking for -  It just has too many details.

Assuming the needs come back, if someone else is maintaining the code, they won't know where to find the (already working) code section in the past. So be kind, and give them a clue - it's not going to be yourself forever.

Ori Berger
Tuesday, May 21, 2002

I used to work on a very large system that was under constant change.  You quickly learned never to delete code that was commented out.  I don't care if it had been commented out for 8 years, you just didn't delete it. 

What you need is a good editor that can toggle comments on and off.

Johnny Simmson
Tuesday, May 21, 2002

I like to delete stuff too, (as you said) with version control software you can always get it back. For VB I use code analyzer (aivosto) and it gives you a listing of dead code/variables etc, I always do this at the end of a project and I am ruthless, but then I've got the type of personality that likes a completely empty inbox etc, less is more in almost all instances for me. Removing dead code gives the next developer a chance to see whats going on.

Tuesday, May 21, 2002

There is a strange reluctance to delete code.  It feels like one is throwing out a valuable heirloom!  But I can't actually recall ever needing to uncomment some of this 'saved' code. 

Do other people have stories of how commented out code saved the day?

Tuesday, May 21, 2002

Commenting out and not deleting unused code is the practice that causes software to (eventually) "be maintained to death". 

I personally like to delete as it is more in like with what I consider "proper refactoring", extends the effective maintainability life of a system, and generally improves the overall quality of a change (e.g. by not coding in a condition or other handling thingie for something that is obsolete - as a unused function when all of the function calls have been commented out, but (bad practice as it may be) the function sets a global switch)...

But I have fought this practice and usually don't win.  These are the excuses:

1) All code is valuable and must be preserved.
2) If it wasn't important it wouldn't have been there in the first place and I might need it again.
3) History of prior changes might be significant (ignores the possibility of any any radical changes)
4) You can't see deleted code in a code walkthrough (even though we did none).
5) If everyone deletes unused code then someone might blame me for deleting something I didn't.
6) I might be seen as not working as hard as I can because deleted code has nothing to show for itself.

On one project, I remember one 5000 or so line module that was over 80 percent commented code.  But commented lines happened to be included in the "lines of code" count for the application and several managers (especially those from the consulting company) thought it was impressive enough to maintain the practice of commenting out code so that the LOC didn't get reduced.

Joe AA.
Tuesday, May 21, 2002

>Do other people have stories of how commented out code saved the day?

I would not call it saving the day, but with some undecisive customers, commenting code out and back in proofed to be a quick way to adapt to their changing wishes. ("I think I would like the print button in after all"...)

I also like to leave debugging and profiling code in as comments. I am no friend to #ifdefs, because they confuse me a lot. When I comment something out, it turns green in my editor and that is plain to see. #ifdefs tend to become invisible, especially if the code spans more than one screen page.

When I actually change code, I normally do not leave the old version in for a longer time. Once the new way has proven to be working, I delete the old code for good (still have it in the source control system for emergencies, of course). Sometimes I am even too eager with that, at least I remember two or three times when I had to fish the older version out of source control and wished I would have left it in which would have saved me the effort.

Have fun,

Jutta Jordans
Tuesday, May 21, 2002

I "kill" code all the time.  I almost always have to inherit something from another author for at least part of any project.  At the outset, I establish the following rule:

If I can eliminate it, I will.  Why? Because if it can be eliminated, then it serves no useful purpose.  Code that serves no purpose will only come back to haunt you.  It often contains dependencies and behavior you do not know about.

This goes to the subject of quality.  One reason companies went to "just in time" inventories back in the '80's was to expose weakness in their process.  If a supplier was consistently late in delivering goods, then it exposed the problem - rather than compensating for it (by compensating, the company would stockpile inventory, masking over the issue).

In software, if a glob of code is poorly written and not understood, then the first thing to do, IMO, is break it (time and resources permitting).  Unravel it, deconstruct it, understand it, re-write it and document it.  And then, once you've got your solution and verified it, put a bullet into the fellow's head who wrote it poorly in the first place.


Nat Ersoz
Tuesday, May 21, 2002

Depends... If the old version has now been replaced with a new "better" version. Then I'd delete the old code after a short while.
Commented out debug cruft (e.g. debug.print for VB) I'd tend to leave in as one day you may want it back again.

Peter Ibbotson
Tuesday, May 21, 2002

Our coding standards actually say that
there must be no commented code when
checking code in.

Going back to old versions is what the
source code control is for.

David Clayworth
Tuesday, May 21, 2002

Old commented-out code is generally worse than useless. If it's been commented out for more than a few months, the chances of it actually compiling and working if you uncomment it are nil.

I've read *lots* of code. My usual approach when reading code with lots of commented-out stuff is to make a private copy and delete the weeds before reading. Remember that if you want your code to be an asset and not a liability, then it must be readable and understandable by those who follow you. Commented-out gunk in the middle of the code usually defeats these objectives.

Jim Lyon
Tuesday, May 21, 2002

I fully subscribe to deleting old code and letting the version control system do its job.

At my present shop, I am *not allowed* to delete code and it drives me nuts. (I should note that I've programmed twice as long as anyone here who is responsible for these types of rules.) Most of the systems that I maintain here contain around 50% dead code. The worst is the presence of several variations of the same class, only one of which is invoked by code that is not commented. I have on many occasions wasted an hour looking for a class that was responsible for a certain task because the route was so twisted with this stuff. (I cannot always begin by stepping through code because I can never attach all of the devices that we communicate with. I generally have to do some winnowing of the problem "by hand" before I go to the storeroom to get the devices I need.)

The basic feeling of my coworkers is that all of the pain is worth it because it lends us job security - i.e., no one could possibly come in off the street and maintain these systems. Since I was out of work last year for five months I do sympathize a little, but I'd rather work in a good environment and not suffer the productivity hit every time we hire someone.

Tuesday, May 21, 2002

David and Jim mention that they abhor commented out code (paraphrase), which I tend to agree with.  But, just now, to debug a problem I uncommented some very useful debug code, which helped solve the problem.  Hmmm...

Nat Ersoz
Tuesday, May 21, 2002

At my work, many people leave old commented code. I can't stand it. The old code was commented out because it DID NOT WORK, but I still have to look at it everyday. It takes up valuable screenspace and my thoughts (as I mentally skip over it).

I think there is one case where commented code is reasonable. If there is a very subtle (perhaps OS-specific) bug, including a snippet of the old buggy code PLUS a big comment explaining why it won't work so don't you go try this. In this case, pseudo-code is probably preferable to real code, otherwise some dufus will try to uncomment it and reuse it someday. ;-)

Like someone else mentioned, people treat old code like an heirloom. Someone wrote that code once upon a time, so it is reasonable to assume that someone else could recreate it one day if necessary. Let's make smaller programs and reduce our KLOCs!

(of course, the same project I work on has many functions that are thousands of lines long EACH.)

Zwarm Monkey
Tuesday, May 21, 2002

How often do you clean up your desk.

Don't put away that book, I might need it!

Tuesday, May 21, 2002

I almost always delete dead code.

As someone else sugested, I also keep a section at the top that talks about any functions that were outright removed. I don't bother if it was just a block of code within a function.

As for debug info, who has debug code? I mean, gee, can't you just write it correctly the first time? :P

Marc LaFleur
Tuesday, May 21, 2002

Clearly, there is no "one size fits all" answer to this question.

Sometimes, though, it's quite clear that certain code can be deleted such as code related  to a library change (e.g. proprietary FTP library to winsock, 16bit Windows to 32bit Windows).

On the other hand, keeping commented-out debug code around might be useful since the debug code is not necessarily "obsolete".

In many cases, just keeping the commented-out code around is just plain confusing. If the new code works, who really cares how it was done previously (incorrectly)? The commented-out code also makes simple "grepping" much less useful.

Typically, I don't keep commented-out code around because the old code has no value (that's why it was replaced).

I might keep commented-out code that relates to "important" calculated results (e.g. pension amounts) since knowing the history of these kind of changes might be important in understanding how the value changed.

Tuesday, May 21, 2002

Interesting thread this...

This is where Unit Testing can be used to save the day again. Note that writing unit tests for existing code is NOT for the faint of heart. However it's a great exercise for someone who wants to understand what a piece of code does.

Moreover, the tests also document the code and bring to good use all the comments placed in the code akin to

/* we added the c == 5 test to check for bloob-prats in the zweegs. */

With that comment, you are sure to make a test case with bloob-prats in the zweegs...

Anyway, once you're done with writing the tests and you are satisfied that they do what you want them to do -- unit test the code -- you go about REFACTORING the code, which basically means you can do what the hell you want to do... As long as the tests run, since if they run -- the code does what you wanted it to do.

Tuesday, May 21, 2002

I'd like (again) to quote Edsger Dijkstra in saying "A line of code is a liability, not an asset". Every compilable line of code, whether commented or not at the moment, is a liability - you read through it when maintaining the code; You sometimes update it if you update the code (heaven help you if you don't, and later assume the code just works).

Measuring productivity by lines of code is similar to measuring value of a project by its cost. Not really smart.

Ori Berger
Tuesday, May 21, 2002

I think Amir is on the right track.  The only value in old code is that it might help you understand the history of development of the module.  That, my friends, is why you use normal comments.  Don't just comment out the old code, preserve the algorithm and the intent in a descriptive natural language of your choosing... and no, obscene blue streaks do not constitute good comments.

Wednesday, May 22, 2002

The other similar thing are people who insist on putting in comments saying why they changed something.

Things like :-

// Changed i to i-1 to fix off by one bug

Nice, but the bug isn't there any more so who cares what the code used to do and how you fixed it. Usually people who do this put their initials and the date of the fix in too. As if anyone will ever care. I just delete this kind of stuff whenever I see it.

John Burton
Thursday, May 23, 2002

John -

I partly agree with your sentiments about bug-fixes.  Well, I'll have to since I have deleted a whole load of such things in the last four days.  However, there are circumstances where these things are worth preserving, just as a warning in case people feel like "optimising" what seems that pointless code.

Mark Alexander Bertenshaw
Thursday, May 23, 2002

John Burton's example just above is the kind of message that's ideal for version-control comments.  When committing your changes, that's when you add a comment into CVS or RCCS or what-have-you explaining what you've changed.

The only reason I see for in-code comments of this kind is when a particular piece of code has been "optimized" at least once, in a way that seems sensible at first glance but introduces bugs.  That's when you add the warning.

Brent P. Newhall
Tuesday, May 28, 2002

*  Recent Topics

*  Fog Creek Home