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
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.
-
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
Monty2 wrote:
I really get pissed off if i come across commented code
I hate commented out code too. It's distracting. If a line or two is commented out AND there's another comment saying why this code is not valid, then that's OK -- serves as a warning to the next guy who might re-implement the bad code. If I see commented out code, I just delete it without contacting the author. -- modified at 18:32 Thursday 23rd March, 2006
-
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/Visual SourceSafe is NOT a tool that you can depend on. I've experienced a serious data corruption while using it on relatively simple project. Przemek http://cafesuite.net
-
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 you're using a revision change system, you should delete the code. If it turns out the change has some unexpected side effects, then you can always go back. If you don't have such a system, comment out the code, but make it VERY clear it is commented out. I've used older editors that do not colour code comments, where a huge selection was commented out -- but it wasn't obvious. That's when you really mess with your mind. :confused:
-
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
A comment should explain reasons and give warnings. If alternative code may be used in special circumstances, then use conditionals around it. Otherwise, any blind-alley code, or stuff I may use again, I put in a text file called unused.xxx, here snippets of code/classes/whatever can be put, and the comments to memory- jog where it was used, do not need to follow the programming language syntax.
-
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
Actually, I nearly tried everything! commenting and typing date&time, deleting. I finally made a simple program that archives my sources everytime a modification is saved to the source, using a filesystemwatcher, it copies the source to a specific folder (%FOLDERNAME%\slnName\24-03-06@10'17'31.225 - SourceName.cs). I'm satisfied because it works quite good! :: it's YOU that makes history :: ^_^
-
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/I use regions for commented blocks that I am not quite ready to remove i.e. #region deprecated 2/26 /* COMMENTED CODE */ #endregion I use this both internally in methods and on the class level. From time to time I search the code for these entries and delete those that are more than a few days old. Brett Nieland
-
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 think that if you're using a versioning system, then commenting out code just adds unnecessary clutter, and makes code harder to read, understand and navigate.