How long should you keep old code commented out in your code base. The contractors continue to keep old code in code base by turning it into comments. This is really frustrating and I want them to just remove the old code instead of commenting it out.
Is there a valid reason to keep old code in the code base as comments?
Update: Version control by Visual Sourcesafe
If you use something like SVN or CVS, no. I would erase them on sight. They make code less readable.
Comments should be there to help the programmer who is reading the code, explain stuff, etc.
Yeah nuke it on sight. It gives no value other that to show that the developer that commented it either wasn't sure about the removal of it. Or they don't know how to use your source control software.
Tell the contractors to stop doing this. This is a terrible practice.
There isn't really any reason to keep old code in the code base; it just gets in the way. Your version control system will show you the history of each file.
The only possibly good reason for keeping old code there is possibly for historical reference (perhaps if the old code did something particularly strange that might be relevant for the current situation).
Occasionally I will just comment out code knowing that I am putting a temporary change in (by temporary I mean less than a few days) and definitely plan to go back to it.
edit: another related practice is putting names and dates of changes in the file:
// 06/20/2009 - joe changed this #1245
Don't do this either. It might seem valuable at the time to see who made a change, but over time it really doesn't have any value and also clutters up the code.
A valid reason I can think of is this (fictional) example:
# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a
Basically, to keep other developers from reinserting the code that was removed for a reason.
Basically, you only have 2 options.
Otherwise, above mentioned are your only 2 choices. Your call!!
If you are using source control which you should be, then remove the old code as a copy will be in source control ready and waiting for you if you ever need to add it back. Having the old code in there will reduce the ability to read the code as stated above and introduce confusion. Also if you are using contractors to write your code tell them how to code as you are paying their wages. Define coding standards for them and get them to code by intention which should improve the name of methods, properties etc and reduce the need for comments all together.
When you remind the contractors they don't have to comment out code as Sourcesafe will keep the history ask them why they're doing it.
It might be that they don't trust it for some reason. If you can get that reason out of them they might pay attention. I know when we moved from VSS many years ago it was because of reliability and scalability issues that they might have been exposed to as well. If you can address their concerns, either by demonstrating that VSS is adequate for your needs or by saying you'll investigate other source control solutions (if you have the budget for it of course), you should win them over.
Persuasion is better than coercion.
Keeping the old code around just makes it more difficult to read the code as a whole. As long as there is some form of version control in place for the project, the commented out code should be deleted. If you don't have revision control and can't set any up, then placing the old code in a file somewhere not part of the code base is advisable.
I'm assuming you refer to significant code blocks that seem to be of some value, or good algorithms in their own right, not just the odd line here or there.
In these cases, there's a natural tendency to keep the code, if you've made large changes keeping the old as comments acts as a form of code review. Anyone getting the latest version will be able to instantly see the large changes that were made, and if there is a problem, its much more easily seen what used to be there. If the problem is with the new code, then there's a very simple way to instantly check it.
So, given that, I tend to comment out old code for the first revision, and then only delete it when the code is subsequently changed again, by this time the change will have been 'bedded in' and not likely to be a cause of bugs.
These comments are a form of documentation, there's no need to remove them for any purist ideal of 'clean' coding. Remove them when they are no longer needed, keep them while they may be of value.
You ask "how long?" I'm not offended by having old code in one or two places if those are the hot spots where people are still working.
Maybe they don't feel confident about the new code yet. Is the new code "done?" Is it written as it should be? Does it pass tests? Is it commented and documented to spec? Is the performance where it should be? (The best reason I can think of to have the old and new code both around is when I'm timing or profiling a certain set of cases.)
Is there anything about the old code that is preferable to the new code?
Do the contractors feel in a rush? Or is it just an old habit from pre-version control days?
First, I say get rid of it.
But I know one reason not to: while it is still there in your version control, that doesn't mean anyone can see it. If you might need to see it again, you first have to know that it once existed. Sometimes you make a modification that future developers need to see both the old and new way and if you remove the old way, how do the devs know it was once there? Most people don't document changes in version control well enough for this kind of problem.
Those who say to get rid of commented-out-code because version control tools will solve any problem you might run into, are idiots.
You need to get rid of obsoleted code, ONCE YOU ARE POSITIVELY SURE THAT IT IS REALLY REALLY OBSOLETE.
Ever had to revise a modification because "it wasn't entirely bad, but alas it wasn't entirely good either" ? If you can still take out the production source and KNOW that the previous version of the code is still in there, in some textual form, it will save you a lot of time, because you will not need to resort to complex, difficult-to-control and therefore very error-pronce processes of using any "partial source merging" and "partial source consolidation" that your version control tool may offer you.
People who don't like this reality surely must have spent their whole careers producing only code that never was "not entirely bad, but not entirely good either", or in other words, producing only code that was either entirely bad or else entirely perfect. And we all know how big the probability is of achieving the latter.
So many reasons to leave the old code there. Basically - once it is deleted it is effectively gone - unless somebody actually remembers it was there.
As an evil contractor I don't delete code unless I am doing a substantial rewrite of a procedure - scrapping it and replacing it rather then "fixing" it.