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.
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.
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)?
Feature-creep is the most common case for unwanted code, bugs and maintainability issues.
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).
I was talking deleting code that's about to be rewritten, or that just doesn't work, but this is a great twist!
When taking out a feature, I don't think of it as code (unless a feature is dragging the app's performance to the ground). So I take it up with the person in charge (sometimes, that's me) and urge the approval of its removal.
Taking care of users is the fun part -- because if people are furious about a missing feature, they're passionate about what you're building. Nothing compares to that, eh?
No it doesn't. Your version control system will keep the deleted piece for you forever.
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.
Yes. When I first started using version control, the freedom to refactor and delete old code confidently was a thrill. These days, even a tiny, short-term project can get the benefit of version control; it's as simple as `git init`. There's no reason to leave commented-out code in a file anymore.
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.
I agree whole heartedly. When you commit you're free to do drastic restructuring, leading to better thought out code. In the worst case you can revert to an earlier stable point but I find that's almost never needed.
This is also a situation where code reviews would help. Unnecessary/redundant comments are badly considered forms of communication between coders. When someone is going to review your code critically it forces you to be clear and concise, otherwise they'll call you out on it.
I'm talking about the devs that do use VCS and yet they still use the comments to keep track of changes. You can tell who they are by looking at their commit messages. "Commit for 24-Mar-2011" is a dead giveaway. :-)
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.
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.
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.
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.
If you put a line of comment above the code explaining why it is there then that would help anyone browsing over the comments.
I read a comment once: "Uncomment this if the site crashes!"
And there was an SQL query commented just below.
While that does make for pretty bad code, I guess you need to take circumstances into account. Stuff like "did they have time or budget to fix the bug the right way?" "Is this piece of code meant to run when testing the app locally so it doesn't send emails?" And all that jazz.
But, as you pointed out, an explanatory comment does wonders and conveys the right context for the commented code -- which was my original problem.
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.
No code should be commented. Ever* . Comments should only contain text in english (or what ever language you + your collaborators/people you have to maintain the code in future speak.)
* Well, Unless you are not using Version control, which is criminally bad. There is absolutely no reason to not use version control.
I disagree with this. I actually comment out code to show what the end result would be.
If have a piece of code that iterates over to create the json to make a gallery object. I have done what the json end result should look like and commented it out so if anyone comes back in future they can see what I have done and why I have done it.
I suppose you could argue that the code example is a comment but it is code at the end of the day
Why not actually write an example (like a short blog post, containing some code snippets), in the comment, using the native language, instead of commenting the live code?
Dont you think it would improve the readability of the code? Sure it takes slightly more time, (may be 10 extra mins, for a small example), but I can assure you, a newbie, who is new to the codebase/language, would certainly appreciate such an example. (I know, I would have.)
If someone is looking over the code and right above the recursion see's an example of what I am doing in my eyes makes it more readable.
Don't get me wrong, it's not something I do every day, I may have done it 3 or 4 times in my life but I have done it. I mainly do it for debugging purposes. If you are stepping through and you can see a string example of the output you can instantly compare it to your built string of JSON.
I am probably just being pedantic but I can see a use for commenting certain code. If i blog posted it and changed it then I would need to make an active effort to update the blog. It would be like maintaining documentation. I can just update the comment above and be on my way.
I think everyone has their own methods and I'm not saying yours is wrong, I am just saying I do see a need to put code in comments sometimes.
There are only two devs here though and we know what we are doing, if a noob came in then to be honest they wouldn't be touching my code until they understand it anyway
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.
It does courage to remove code if you have to deal with customers or users that, it turns out, relied on the feature.
A good example of this is Google Docs. In the first version of Docs, it was possible to change CSS style sheets and make changes to the low-level document. You could change background colors and so on.
In the rewrite they removed this functionality to achieve "more simplicity". However, many people were relying on the customizability, so they have a ton of complaints about the new version.
It appears that the current decision is to keep the old version "forever". Of course, whether this is true remains to be seen. But the lesson is that even if you think a certain feature is useless, people might be relying on it. You're never sure how customers are actually using your program.
So if you "boldly" delete something you might end up maintaining more versions, have to reinstate the deleted code, or lose customers. I think that's where the courage comes in.
To your users, removing something from the latest release is equivalent to throwing away the code. Sure, you can trivially bring it back using source control, but the user can not, so the damage might already be done.
End users do not get affected by commented code. A more direct and positive way of making sure that the users do not get affected, would be to be responsible and actually test the code before putting it in-front of the users.
No it will not. That is a business decision anyways.
I dont think this is what the post is concerned about. It is about the dead code, developers leave as commented (for some reason), instead of actually deleting it.
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...
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.
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.
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.
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)?
Feature-creep is the most common case for unwanted code, bugs and maintainability issues.
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).