Best practices question: do you comment out or delete old code?
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
I comment it out, make sure things work, then I delete it. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
-
I comment it out, make sure things work, then I delete it. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
It will get deleted eventually. The code will get commented out to start with - Just in case I realise I'm taking the wrong track or I need something that was there. Once everything is taking shape I start to delete the stuff that I know I won't need. By the time it is finished all the old code will be deleted. So, in short, there may be a version or two with commented out code, but it gets cleaned out quickly. ColinMackay.net Scottish Developers are looking for speakers for user group sessions over the next few months. Do you want to know more?
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
I comment it out until I'm confident the new code is right, then I delete it. And there's always source control to retrieve it if I really screwed up. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
It depends on the code; it serves no purpose to have a hard and fast rule about this. Sometimes I'll keep code commented out for future reference (if it's, say, a complicated algorithm I've rewritten and I want to keep code that definitely works handy), but in most cases I'll depend on source control to look up old code as the need arises. In fact, using source control for this sort of thing is much easier (at least it is with subversion) because it is simple to look up the history of a particular file or even individual lines of code (via the blame command), and then you get dates and times of every change, and you'll know if that block of code affected some other code elsewhere in the source. Viva Subversion! :)
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
Well i don't like to keep the commented code at all. I usually put it in notepad and very rarely do i save that notepad file, it just lies there untill whatever i was coding is done and tested properly (well to a certain degree :rolleyes:). I really get pissed off if i come across commented code and that too in SCM, can't you write it again you have to, cause *you* wrote it in the first place. Anyways what do i know, i am just an excellent coder :-D.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
I always aim to delete before checking back in. That way the diffs reflect more accuratly the changes that I have made. I cant abide seeing pages of commented out code that someone left in "just in case" in stable source, it's a sign of bad scc usage. Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven." - Penn Jillette
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
With a robust source control like Visual SourceSafe and an excellent developer-friendly IDE like Visual Studio.NET 2003, I don't think we need to support the old styled .bak and commented codes. We do have #region and #endregion to support us and enhance the code presentation. What do you say? Vasudevan Deepak Kumar Personal Web: http://www.lavanyadeepak.tk/ I Blog At: http://www.dotnetjunkies.com/weblog/deepak/
http://deepakvasudevan.blogspot.com/
http://deepak.blogdrive.com/ -
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
It's commented out first (mostly because it's written by people I can't ask anymore) and a date is added When I'm working in the same place again, I delete old stuff that has dropped to "Acceptance level".
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
I comment it out first.Then when the algorithm seems fine,delete off the commented piece. I however keep track of every bit of my modifications as a simple html file.The file starts with the latest code and follows with a history of changes,the reason etc. This works for me. -vmmk
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
Well the coding standard says 'no commented out code in a release build' In practise this usually means leaving the commented code in the source until I'm happy with the code that has replaced it. The commented code is then deleted before the check-in. To keep the history, I try to check-in code on a "taskitem completed" level, rather than checking multiple code changes in one check-out. Michael CP Blog [^] Development Blog [^]
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
If the code in source control, why should we keep a copy of it in the source? I just delete it. In case I need to review it again, I do in in source control (difference). Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
Since using sourcecontrol I delete it straight away. If it was errornous I am always able to get to ALL the old versions and revert the changes. Since I am using sourcecontrol I can't stand .old files or commented out sections any more.
All the label says is that this stuff contains chemicals "... known to the State of California to cause cancer in rats and low-income test subjects."
Roger Wright
http://www.codeproject.com/lounge.asp?select=965687&exp=5&fr=1#xx965687xx -
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
If I'm editing existing code (mostly written by other people) I comment it out and put a region around it so I can collapse it. Once the new code is stable and approved, the commented code is deleted. Like most other people, I rely on source control for historical references.
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
Since most of the code I work on is for executable apps, not web based, I don't mind leaving commented code in place... who's going to see besides a developer? I like the commented code because it shows what was change, and, presuming comments exist as well, why. If the code has been there for an extended period of time and can no longer serve a purpose, then I will delete it. A good example of this was some code written in Fortran where the IF block was 23 lines long... the comments were as long or longer explaining exactly what is was doing, but the old code was left in place to show what it HAD been doing.
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
I prefer to physically delete code that's no longer in use. If necessary, I might add a brief comment indicating how the method used to work, but only if necessary. I endeavor to write meaningful check-in comments that are viewed when you examine the history of a file in source control. /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
Yes, it's that time again. ;) When you check out code to make changes, do you comment out old code or delete it before checking it back in? If you comment it out, you can see the history but end up with bloated code files and navigation becomes difficult with so many comments. If you delete the code, you don't see the history and might make the same mistakes you (or worse, somebody else) made. I asked my boss and he suggested the middle ground - comment out the unused code, but delete them after some time (like maybe 10 revisions, or one year, or whatever). I'd like to know what practices you blokes follow. :) Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
I will start with commenting out. I normally delete that code immediately if I did a silly mistake or a code that I am ashamed of (because I did not use test first development). Gradually at different stages of refactoring the comments will go away and the code will be cleaner. I don't like the entire history of the modifications be written on the top of the file. The best example is Oracle OCI include files, the length of the history comments is sometimes more than the content of the fiel itself.