Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 8 down vote favorite

This question already has an answer here:

I've found, what I personally believe to be a bad habit that a lot of developers seem to have adopted. Code in various places in the applications I have seen are commented out (lots of it) and checked into the mainline. Now, I don't have a problem with people doing this with their own branches, but is it a good idea to comment out 60 or so lines of code and check it into trunk? A colleague of mines has unearthed a lot of this and had spend half a day removing the commented out code just to tidy things up. Is there any benefit in checking in commented out code and leaving it for another developer to have to tidy up after you? After all, version control does have a history, so you can easy pull back any code that's been removed.

share|improve this question
3  
We actually have a directive at my work that NO old code is to be removed, only commented out. If it gets untidy, then comment out the entire block and recontruct the code in a tidy manner underneath the commented block. Also, copious comments should be left to track who changed what, and when. It's not as if we don't have version control... about a year ago we started using Visual SourceSafe. Personally I hate this system. Bad company smells, perhaps? – nakedfanatic May 4 '11 at 1:50
2  
@nakedfanatic - In my own opinion, it comes across as laziness. You comment a block of code while debugging as your sure your going to come back and uncomment it, but for some reason, you forget about it and don't bother removing it. Yesterday I was fixing a bug and saw something like 90 lines of code commented out in trunk and it was ugly as hell. With version control you can always peruse the previous revisions to see what code has been added/removed/modified. So your work's directive is a little strange as no old code is ever removed from version control; It can be restored at any point. – Desolate Planet May 4 '11 at 9:39
At the company I worked for, it was an old habit from before we started using SVN. So, some people were used to do it, and there was still a lot of old code that was not changed using SVN. – Geerten Jan 18 '12 at 13:47

marked as duplicate by gnat, Kilian Foth, Frank Shearar, BЈовић, Mark Booth Mar 12 at 11:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6 Answers

up vote 21 down vote accepted

I see no benefit to this, especially in the main trunk.

Commented out code only provides a quick way for a developer to roll back. The whole point of source control is to have every working version, so that you can keep track of what has changed.

http://blogs.msdn.com/b/abhinaba/archive/2005/11/22/495701.aspx - talks about commenting out large blocks and why they are ugly, and hard to maintain.

Comments do not get verified, and do not evolve with the code base around them. In that way, the commented code will NEVER be valid in the future.... so why keep it at all when there is a perfectly good version that compiles just BEFORE it in the commit list of the main trunk?

share|improve this answer
2  
+1 large blocks of commented out code is the work of the devil. Especially when it starts with a comment Never use this. I've even seen it when a program has been ported to a different language and the previous implementation has been left at the bottom. – Ben Sep 4 '11 at 13:10
Saying there is no benefit to it is a bit short sighted, don't you think? – Rob Sep 5 '11 at 1:25
The question is about commented out code, not comments as a whole. Commented out code is NEVER executed, does not have any tests associated with it, and is thus never verified. It has NO value in the future of any project. A few lines of descriptive text that describe a change in code are a perfectly valid way to communicate some descriptive history of why large changes were made. – Jeff Fritz Sep 7 '11 at 15:39
@Ben: Commented out code that starts with a comment Never use this can be a good thing, as long as it explains why you should never use it, and as long as it's not littering up your code base. I've used it before where an obvious and simple solution turns out to be the wrong solution, and I want to prevent future coders (including myself) from going back to "improve" it. That said, if such comments aren't rare, you're doing something quite wrong. – Ben Hocking Feb 22 '12 at 22:31
up vote 5 down vote

There are only two decent reasons for doing this that I can see:

  1. the change is intended to be temporary, and a reminder is needed to put it back (ie. it is kept in as a placeholder)

  2. the code was added for test purposes that for some reason had to be in situ, and may be needed again

share|improve this answer
3  
3. As documentation for what was tried in the past, and found to be lacking. This shouldn't be large chunks of code, but small snippets. For instance, if the obvious way of doing something leads to performance problems. – KeithB Mar 2 '11 at 19:11
@KeithB: Aye, and Renesis's point for 4. – Orbling Mar 2 '11 at 20:45
up vote 17 down vote

There is a good reason, but it probably doesn't often extend to large chunks (60 lines sounds excessive - a small note could have been used instead).

Sometimes you may have to remove some helpful code because the feature requirements change. If you envision that code being useful in the future, commenting it out can be helpful to prevent a future developer from starting from scratch, not knowing that your code ever existed.

Version control gives you access to history, but it doesn't teach you about it..

share|improve this answer
3  
+1 for final line. – TZHX Mar 2 '11 at 12:30
2  
I think this is an example of a more general case--things where a future developer wouldn't realize that examining the history would tell him something useful. – Loren Pechtel Jan 16 '12 at 23:44
What would be most productive for the future (most probably junior) developer? starting from scratch or trying to figure out how to incorporate ancient commented out code in new codebase? Don't let history weight too much, even commented out. – mouviciel Jan 18 '12 at 13:10
If you have to remove code, but you may want it back in the future, just write a (short) comment to that effect. Like "Code to frobnicate the barf removed in rev.3953". That does not clutter the code, but tells other devs the code existed. If after a few months you find you don't need the code, you can remove the comment. – sleske Jan 18 '12 at 15:40
up vote 1 down vote

The modifications can be tracked by version control systems such as SVN. It's easy to see what've done from one version to another. It is no necessary to comment out unused code if you wanna check in to SVN.

I think they comment out the code mainly because they may want to recover what've modified or they're not sure the new modification is correct.

Comments are just "comments", having version control system, we got to keep code clean and tidy.

share|improve this answer
up vote 1 down vote

With a good version control system (like git), one can quickly and easily create a branch to hold code that might otherwise be commented out and committed. Or, one could commit the commented-out code, then remove it and commit again.

share|improve this answer
up vote -1 down vote

commented out code also acts as a quick and simple version history. If you don't see the comments, you don't know what was there - regardless of the versioning. I tend to comment out blocks as I'm developing, and happily check them in. However, the caveat is that I will happily remove comment blocks for freshly-checked out code, the intention being that the next revision will always have the comment in there for the next dev to see when debuggging (assuming I make a mistake, they can instantly see what it used to be when it worked) but after that revision it becomes redundant and can be removed. Obviously you need to apply a little common-sense to this, sometimes the comment should be left in for a bit longer, and it doesn't apply to all commented out code.

share|improve this answer
1  
The OP obviously has source control in place. What's wrong with "View history" or an equivalent command in whatever toolset you're using? – Michael Kjörling Jan 18 '12 at 14:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.