|
Inactive code clutters up active code, so I remove it instead of simply commenting it out
|
|
|
|
|
Anyway since there is version control on professional code , there is really no point in keeping code that has become obsolete. Moreover people will ask themselves why it is in comment. If it is in comment they will definately ask themselves, why is it in comment. So if you really do this, then there should be a comment statement to document the reason. All the more reason to remove it and specify the reason when you commit your code in the version control system you use.
Which brings me to the point of comment itself. If you feel the urge that your code requires comment. Then you should rewrite your code as such that it documents itself. You do this by breaking up the code in little maintainable pieces, clear layering, top down approach, clear variable, function, classes and method names, ... all the stuff required for clean code.
|
|
|
|
|
Philip Stuyck wrote: Anyway since there is version control on professional code , there is really no point in keeping code that has become obsolete.
Full approval on this point!
Philip Stuyck wrote: Which brings me to the point of comment itself. If you feel the urge that your code requires comment...
This certainly applies to most inline comments. But what about commenting classes and non-trivial methods?
|
|
|
|
|
The whole story is about maintainability of the code base.
I'm also tempted to comment out code once in a while, especially when I'm elaborating on some algorithm in an early phase. If I commit commented-out code, I regard it crucial to tag it with e.g.
Commented-out code without TODO tag is a no-go for me. Reasoning: when you or someone else comes back to that commented code block, you have no means to understand under which conditions this code might become active again.
Beside that, there are better and worse ways to "comment-out" code, depending on the language, e.g.
...
...
...
if (0)
{
Statistics s = calculateStatistics();
dumpStatistics(s);
}
...
#if 0
Statistics s = calculateStatistics();
dumpStatistics(s);
#endif
...
...you name them...
I prefer, if at all, the first one (//...). The editor colors the comments such that it is obviously inactive.
The second comment (/*...*/) breaks if nested.
The third approach (if (0) ...) usually does not get coloring support from the editor and you have to constantly maintain it since the code still has to be correct.
The forth approach (#if 0 ...) may also lack editor support too but at least, the code does not need to be correct.
Now, what is the motivation to comment out code:
a) hoarding (it may be useful in some far future...)
b) short term fallback (backup since I'm not sure yet if the alternative code works)
c) some debugging/testing aid (uncomment code if debugging/testing)
d) other?
Case a) usually cost you more than it helps. If you really think that this code may be useful again: did you ever happen to re-activate such code? My observation is that hoarded code very very rarely gets re-activated. Reason: the code base in that far future will have changed so much that writing from scratch usually leads to a more sound solution than trying to squeeze the "old" code into the new code base. Alternative: remove that obsolete code and commit with a decent version control comment, like: removed experimental code for algorithm xyz.
Case b) is reasonably useful, but if committed, please add a TODO tag.
Case c) is really dangerous! I've seen go such code undetected into the product being only detected very late that it was activated by accident. My advise is to find other ways to control such code, e.g. by #if CHECKED_RELEASE (included/excluded at compile time) or if (validate) ... (activated at runtime, e.g. via command line args) or similar means. This case c) is sometimes observed as crude alternative to proper Dependency Injection: "for debugging/testing use another object than for productive code", etc.
So:
1) try to avoid commented out code by removing it ASAP (with a decent version control comment)
2) if there is commented out code, tag it with a resonable TODO
3) follow up frequently on TODOs, i.e. go to 1) (remove that commented out code  ).
Cheers
Andi
|
|
|
|
|
I use this strategy sometimes.
Commented writing date of comment.
waited to 1-2 week to see if all work as expected.
After that time passed I'm pretty sure the commented code is not anymore useful for reference nor for reverting so I delete.
Anyway code is versioned so deleting is no big deal but having it commented for some time it's kinda practical
|
|
|
|
|
I do it the same. Since I'm missing exactly this answer option I vote here.
|
|
|
|
|
I'm wading through a sea of crap due to this policy. Or maybe they got cold feet and decided to keep it just in case.
|
|
|
|
|
Funny you should mention it... I read this poll while I was in the process of commenting out some code. Once I've written the new stuff (and it works), the old stuff will be promptly deleted.
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
|
|
|
|
|
I keep dead apps, early versions that didn't make it past POC stage, apps that made it into production a decade ago and have since been retired. I still have old VB6 apps hanging around somewhere. I certainly have a bunch of VB.net apps in a folder on the current machine and all c# stuff is actively searched for functionality I know I have written just not which app 
As for active code, like DaveAuld, I comment and delete only after stability of the new code is proven.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I comment out code regularly if I feel it will be required in the future.
However, if it no longer serves any purpose, I'll remove it.
I like to comment my code too, which helps other programmers and myself understand what is going on.
Did you hear about the thief that stole the salt and pepper?
Apparently he was a seasoned criminal.
|
|
|
|
|
DanielSeal wrote: I like to comment my code too, which helps other programmers and myself understand what is going on
As for commenting code (adding text to describe what's going on) when I see too many comments I'm scared.
If who developed the thing felt like he needed to explain a lot usually is because the implementation itself is a mess.
IMHO, Code should be clear to read and generally commented.
|
|
|
|
|
I tend to first comment it out, then if it stays commented for a while, I delete it. And of course, everything is under source control, so if I need to recover it, theoretically I can. Theoretically, not because of a failing of source control, but because I may not either remember that I wrote it, or how to find it. Yes, I am one of those people that started writing a whole chunk of functionality once, only to remember, as I was going about it, that I had written that functionality a year or so before. And, amusingly, I was implementing it in a completely (and worse) different way!!!
Marc
|
|
|
|
|
True and sincere. I'm on the same side.
|
|
|
|
|
...deleting a few thousand lines of unused code. If it's database tables it's even better  (ok, this implies that I've followed some procedure of quarantine, because you cannot recover data from the source control :P)
|
|
|
|
|
I would be happy to delete any code I've commented over 4 hours ago
And in case there's some code I'm not sure about, I use the famous:
// TODO: Delete when you grow up
// void myUselessOldCode()
// ...
Then every now and again I do CTRL+F on "TODO:" and handle it.
Keeping old code longer than this process not in source control, is rather silly.
Never underestimate the difference U can make in the lives of others.
∫(Edo )dx = Tzumer
∑k( this.Kid) k = this. ♥
|
|
|
|
|
You don't need to CTRL+F if you're on Visual Studio.
On the Task List view you'll see all your TODO's.
Also supported natively are HACK and UNDONE but you can even define your own tags under Tools > Options > Environment > Task List
Cheers!
|
|
|
|
|
pffff, after all these years 
I'd 5 you again if I could!
Tnx Alex
Never underestimate the difference U can make in the lives of others.
∫(Edo )dx = Tzumer
∑k( this.Kid) k = this. ♥
|
|
|
|
|
Source Control.
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[ ^]
|
|
|
|
|
 amen
you want something inspirational??
|
|
|
|
|
Saw this survey and thought it was about code hoarding as in directories 10 levels deep full of collected source code zip files from around the web. *inhales* Turns out it is just about comments in active projects. I am definitely a code archive hoarder. Seeing how a lot of example code out there does not have version control. (I'm looking at you code project) So as for the survey answer, I chose remove old code, except I don't. Use git you'll feel better in morning. Branching is stupid fast with it, in fact, I create branches on a whim to test changes to a single file.
|
|
|
|
|
Deus ex Machina wrote: Use git you'll feel better in morning.
I loathe Git. Biggest Rube Goldberg POS I've come across in a while.
Marc
|
|
|
|
|
Marc Clifton wrote:
Biggest Rube Goldberg POS I've come across in a while.
No offense but that gave me a good laugh. To each their own I guess. I like it though, mind you it does have its drawbacks. git merge is very picky for example. I never liked Subversion with its bandwidth intensive commits. I'm in the Kansas City Area so eventually I will have Google Fiber then it won't matter. I've never really used anything else and I haven't needed to. I can only fit so much stuff in my brain at a time. Whoops there went Java.
|
|
|
|
|
Deus ex Machina wrote: No offense but that gave me a good laugh. To each their own I guess.
None taken - while I have strong opinions about Git, I know I'm the outlier, and so I approach my opinions with humor!
Marc
|
|
|
|
|
For me was a matter of start using it properly.
Before that I didn't even understand why people were so devoted to it.
And the raw you handle it, the better it becomes.
I used to be a TFS user and an SVN lover.
Now for me, TFS is gone and SVN is legacy.
But just to make it clear, is MHO.
Cheers,
Alex
|
|
|
|
|
Step 1: comment
Step 2: run for ages to make sure nothing broken by this
Step 3: delete
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
