Old Code in comments [closed]

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.

回答3:

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.

回答4:

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.

回答5:

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?

回答6:

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.

回答7:

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.

回答8:

Basically, you only have 2 options.

Remove it - thats when you use some code repository. Your repository will tell you precisely what changes were made so there is no need to keep long old comments in your working code, which doesn't explain something in easy language.
On the other hand, if you wish to keep that code for several reasons, example, I kept some floating point calculation code in my application commented out, because it didn't work over the platform, I was programming for. But as I would not want my application to stay limited to that platform, I kept the code there, so it saves the effort when I port the application to a platform which did support floating point calculations. This is just one of the reasons to keep old code, and might be applicable to people of the same background.

Otherwise, above mentioned are your only 2 choices. Your call!!

回答9:

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.

回答10:

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.

回答11:

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.

回答12:

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.

回答13:

The project I'm currently introducing to, uses yet another approach - some kind of compromise... When you decide, that some part of code is no longer to be used, you simply comment it out, write a date of commenting out, and (if it is possible - for example in Netbeans or VisualStudio) you insert the old code in #region OLD_IMPL. Effect? - You still have an old code just in case - Block of unused code takes exactly 1 line (#region OLD_IMPL) - If you see, that code is not used for a year (you have date of commenting it out), you can simply delete it.

In case of any critical situations you always use SVN ;)

回答14:

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.