4 ms·
Yes code should be deleted and then later recovered from source control. In the event it is needed to be glanced at or restored, but you're exaggerating how pr
by Kequc 13y ago
Yes code should be deleted and then later recovered from source control.
In the event it is needed to be glanced at or restored, but you're exaggerating how problematic commenting a method out of code is. If I'm scrolling through code and see a commented out method my brain says "well that's not in use" and I move forward.
If a commented method stays in code for a few months I would complain or simply remove it myself, but it isn't hurting anything (unless in the case of Ember).
- mmatants 13y agoCommented-out code is a "FIXME" to-do item that has no explanation of intent. If I comment out code, I always annotate it with a @todo marker and an explanation of why it is commented out. Otherwise, just delete it - commit message becomes the documentation.
- ufmace 13y agoI generally don't like seeing commented-out code in source control because you don't have any idea why it was commented out. Is it something that you added to debug while in the middle of a bug fix, and thus now useless? Is it a half-done refactoring that you ran out of time for or ended up not needing? Is it an attempt at a speedup or new feature that didn't work out? Did it have some tricky bug and get replaced by code that fixed it? I can't think of any reason to do it that isn't a half-assed attempt at something a good source control system does much better. If you have lightweight branches, blame, and logs you can search and check by date, along with good changeset comments, then you already have everything your commented-out code can do, and all in the same place and system, instead of spread out into several different systems.
- jairtrejo 13y agoThe scary part for me is uncommenting it, because the code has been removed from normal QA and testing (automatic or manual) and you don't know what evils you are unleashing upon the world.
- mightybyte 13y agoThat's because you're not using Haskell. :) Herein lies the crux of my point. Haskell's purity and strong static types allow you to make lots of very strong assertions about what kind of evils you might be unleashing.
- iamstef 13y agoseems like this post should have been titled "What JavaScript(or its replacement) could learn from Haskel"