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
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.
-
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'm using Subversion. I have all my history right there. Delete the cruft.
They dress you up in white satin, And give you your very own pair of wings In August and Everything After
I'm after everything
-
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
Generally, I'll comment out code initially along with the date. Then at some point in the future, I'll get tired of looking at it, or realize that going back to old source revisions is good enough reference. I will put a comment at the top of the function however that I deleted something. Of course, there are times when I just think the old code isn't worth saving and I'll just delete it. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
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/ -
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.
-
Vasudevan Deepak Kumar wrote:
With a robust source control like Visual SourceSafe
Hmmm :~ VSS _is_ a reason why to keep code in comment :) ~RaGE();
:laugh: I was thinking the same thing. I've never heard the words SourceSafe and robust in the same sentence without a negation. ;P
They dress you up in white satin, And give you your very own pair of wings In August and Everything After
I'm after everything
-
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 gets delored. That's what source control and diff tools are for. If there is a question about approach, then a comment explaining why the current code works best is better then having a chunk of old code with old variable names, and getting in the way of searches.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
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
We do things a little different, each programer gets a copy of the source, they make changes and tag them with there initials, leaving all code intact but just commented out, when the changes are tested and added to the main project the comments are removed. Once each section is finished we can download the lattest project where everything is clean and start on our next section. Pablo
-
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 old code makes up an entire file or database object (SQL procedure, table, or column, for example) rename the file or db object with a prefix such as "_delete me" or "_old". That way when viewing your code files or db objects alphabetically, the ones no longer relevant will be grouped together. In the SQL database, if you get a dreaded "object not found" error, you can retrieve the object by simply renaming it.