4 ms·
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
by chrislomax 16y ago
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.
Just my 2 cents
- hdragomir 16y agoI do get your point. 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. Thank you for taking the time to reply, Chris.