Commenting code that is removed [closed]

Answer 1

In almost all cases old code should of course be removed and tracked in your RCS.

Like all things though, I think that making the statement 'All deleted code will ALWAYS be removed' is an incorrect approach.

The old code might want to be left in for a miriad of reasons. The prime reason to leave the code in is when you want any developer who is working in that section of code in the future to see the old code.

Relying on source tracking obviously does not give this.

So, I believe the correct answer is:

-Delete old code unless leaving it in provides crucial information that the next developer in the code would require. Ie, remove it 99% of the time but don't make a draconian rule that would remove your ability to provide much needed documentation to the next developer when circumstances warrant it.

Answer 2

You should delete the code always.

As for being able to see old/removed code, that's what revision control is.

Answer 3

I would suggest that, yes it's good practice to comment on code that has been removed but not in the code itself.

To further clarify this position, you should be using a source code control system (SCCS) that allows some form of check-in comment. That is where you should place the comments about why code was removed. The SCCS will provide the full contextual history of what has happened to the code, including what has been removed. By adding check-in comments you further clarify that history.

Adding comments in the code directly simply leads to clutter.

Answer 4

I'll add my voice to the consensus: put the comments on why code was deleted in the source control repository, not in the code.

Answer 5

A little anecdote, for fun: I was in a company, some years ago, knowing nothing of source code version control (they got such tool later...).
So they had a rule, in our C sources: "when you make a change, disable the old code with preprocessor macros":

#ifdef OLD /* PL - 11/10/1989 */
void Buggy()
{
// ...
}
#else
void Good()
{
// ...
}
#end

No need to say, our sources quickly became unreadable! It was a nightmare to maintain...
That's why I added to SciTE the capacity to jump between nested #ifdef / #else / #end and such... It can be still useful in more regular cases.
Later, I wrote a Visual Studio macro to happily get rid of old code, once we got our VCS!

Now, like buti-oxa, sometime I felt the need to indicate why I removed some code. For the same reason, or because I remove old code which I feel is no longer needed, but I am not too sure (legacy, legacy...). Obviously not in all cases!
I don't leave such comment, actually, but I can understand the need.
At worse, I would comment out in one version, and remove everything in the next version...
At my current work, for important local changes, we leave the old code but can reactivate it by properties, in case of emergency. After testing it some time in production, we eventually remove the old code.

Of course, VCS comments are the best option, but when the change is a few lines in a big file with other changes, referencing the little removal can be hard...

Answer 6

I think it's pretty useless and make the code less readable. Just think what it will be like after some monthes....

// removed because of this and that
/* 
      removed this stuff because my left leg...
*/
 doSomething();
// this piece of has been removed, we don't need it...

You'll spend half an hour to find out what's going on