Well. There's two reasons to delete code. One is to delete code you think is unused or better rewritten. In this case you have unit tests and your source control system that keeps the deleted lines forever and makes it more or less easy to get them back.<p>But if you want to delete code that's in use, that's different. You know: The code might be some rarely used feature, something added for one customers request or something that a lot of people once wanted but is now solved in a much better way but might still have some users.<p>In that case, removing the code certainly takes courage. Can you explain why the feature is gone? Can your users/customers live with the feature being gone (even though there might be a better replacement, they might be used to the old ways)?<p>Feature-creep is the most common case for unwanted code, bugs and maintainability issues.<p>It feels great though once you show the courage to remove the cruft and then you can look at lines over lines of red code (my diff highlights removed lines in red).
No it doesn't. Your version control system will keep the deleted piece for you forever.<p>In the examples the OP is giving, the purpose of code comments is storing the snippets of the earlier code the developer might eventually need. No matter which VCS you use, it is better suited for that purpose. There's nothing heroic about that, so yes, go ahead and delete that piece.
A developer who needs courage to delete code is probably doing things wrong in the first place. With source control and good testing, you should be able to delete code without fear.
Seriously. Once I was assigned to a project with a coworker that commented code instead of deleting it. I explained to him why this was wrong, he kind of agreed and deleted some of the commented code as he saw it, but didn't care much either way. Until at some point, we needed to test a part of the program without a feature, so we commented the code that was related to it. When the time came to uncomment that code, we realized we had no quick way to know which code we had just commented, and what was old stuff that should have been deleted.<p>After we finished with that, we took a few hours to remove all the useless commented code.
I think all this is relative. It depends how "low level" the code is. I appreciate I have it in source control but I will leave it there for a few builds before getting rid of it. If its closer to the UI in terms of code then I will generally just get rid. I suppose it depends how much code depends on that code.<p>I know if I made a massive change in my httphandler code then I would definitely comment it out. I would like to be able to go back in, uncomment and rebuild in the instance old "tried and tested" code needs to be put back up. You generally do change code for a reason and it's generally to improve or because you find a bug but if you have had code running on that function for years and its just cropped up then uncommenting works for me.<p>Like I say, after a few builds and seeing the new code in action I will delete it but I think it does serve a purpose.<p>If you put a line of comment above the code explaining why it is there then that would help anyone browsing over the comments.<p>Just my 2 cents
I could have written this article myself.<p>For me, it is simple. Code maintainability is of paramount importance, and you've got all the history in the version control anyways. Comment is not Code. They are written for humans for maintaining the program, where as code is written for machine to execute.<p>No <i>code</i> should be commented. Ever* <i></i>. Comments should <i>only</i> contain text in english (or what ever language you + your collaborators/people you have to maintain the code in future speak.)<p>* <i>Well, Unless you are not using Version control, which is criminally bad. There is absolutely no reason to not use version control.</i>
Ii doesn't take courage. Just a little experience tells you that code you delete is less code to maintain. And if you want to build anything non-trivial, maintainability is absolutely critical.<p>I <i>love</i> deleting code.
I comment the code out and leave a dated comment telling myself to delete it if commenting it out has caused no issues... I think that's a lot nicer than having to fetch code from a revision control system if you've taken something out that's important...<p>And besides if in a couple of weeks there has been no issues as a result of the refactor it's then very simple to see what to delete.
I remember those days. To this day, I still comment out the old code and leave it until I'm 100% sure of the new code. Hopefully this is -before- I commit to source control, but sometimes it's not.<p>Also, shotgun coding isn't a bad thing in itself. Code, then optimize. In other words, just get it working, then rewrite it better. It's usually faster and cleaner in the end.
When I was younger or when I started a new project, I liked to think about productivity in terms of "lines of code written today". Now or when I'm in a big codebase, I like to measure in terms of "lines of code deleted today".
My question to anyone I catch doing that: Are you saving that code for a rainy day? The answer then usually varies but more often than not they get the point and delete it.