Before you start admonishing me with “DON’T DO IT,” “BAD PRACTICE!” and “Learn to use proper source code control“, please hear me out first. I am fully aware that the practice of commenting out old code and leaving it there forever is very bad and I hate such practice myself.
But here’s the situation I’m in. A few months ago I joined a company as software developer. I had worked in the company for few months as an intern, about a year before joining recently. Our company uses source code version control (CVS) but not properly.
Here’s what happened both in my internship and my current permanent position. Each time I was assigned to work on a project (legacy, about 8-10 years old). Instead of creating a CVS account and letting me check out code and check in changes, a senior colleague exported the code from CVS, zipped it up and passed it to me.
While this colleague checks in all changes in bulk every few weeks, our usual practice is to do fine-grained versioning in the actual source code itself (each file increments in versions independent from the rest). Whenever a change is made to a file, old code is commented out, new code entered below it, and this whole section is marked with a version number. A note about the changes is placed at the top of the file in a section called Modification History. Finally the changed files are placed in a shared folder, ready and waiting for the bulk check-in.
/*
* Copyright notice blah blah
* Some details about file (project name, file name etc)
* Modification History:
* Date Version Modified By Description
* 2012-10-15 1.0 Joey Initial creation
* 2012-10-22 1.1 Chandler Replaced old code with new code
*/
code ....
//v1.1 start
//old code
new code
//v1.1 end
code ....
Now the problem is this. In the project I’m working on, I needed to copy some new source code files from another project (new in the sense that they didn’t exist in destination project before). These files have a lot of historical commented out code and comment-based versioning including usually long or very long Modification History section.
Since the files are new to this project I decided to clean them up and remove unnecessary code including historical code, and start fresh at version 1.0. (I still have to continue the practice of comment-based versioning despite hating it. And don’t ask why not start at version 0.1…) I have done similar something during my internship and no one said anything. My supervisor has seen the work a few times and didn’t say I shouldn’t do such clean-up (if at all it was noticed).
But a same-level colleague saw this and said it’s not recommended as it may cause downtime in the future and increase maintenance costs. An example is when changes are made in another project on the original files and these changes need to be propagated to this project. With code files drastically different, it could cause confusion to another developer doing the propagation. It makes sense to me, and is a valid point. I couldn’t find any reason to do my clean-up other than the inconvenience of a ridiculously messy code.
So, long story short: Given the practice in our company, should I not do such clean-up when copying new files from project to project? Is it better to make changes on the (copy of) original code with full history in comments? Or what justification can I give for doing the clean-up?
PS to mods: Hope you allow this question some time even if for any reason you determine it to be unfit in SO. I apologize in advance if anything is inappropriate including tags.
If copy of some file from another project really means (for this sources) “The point of divergence” and parallel independent evolution of source and fork, than legacy history and commented code are effectively “white noise” and can be easy eliminated on your side. For future possible propagation from parent mentioning of “bifurcation point” only will be sufficient in first line of Modification History, smth. like
Addendum by asker (ADTC):
I wish to quote a comment in addition to the answer above.