Best practices question: do you comment out or delete old code?
-
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.
-
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
When I need to make changes to the code, first I comment it, then, on the next review or when I need to make more changes I delete the code I commented de last time I made changes. That way I avoid to have messing code in my programs. :cool: Fer