4 ms·

The mental effort required to find and pull the old code is far greater than that required to toggle a code comment, or just the line using that code. The autho

The mental effort required to find and pull the old code is far greater than that required to toggle a code comment, or just the line using that code. The author rightly points out bad behavior by Ember: Unused code should not affect program behavior.

ef4 13y ago
But that's a one-time mental cost. There's also the mental cost of navigating among all that commented code every single time you need to read that piece of source.
- 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 ago
    Commented-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 ago
    I 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 ago
    The 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 ago
      That'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 ago
        seems like this post should have been titled "What JavaScript(or its replacement) could learn from Haskel"
Arnor 13y ago
True, but I find commented out code really distracting while I read a file. It's really easy to use the comment method to excess and end up with a file full of old trash code. As far as Ember's issue, we didn't see the actual code. There's almost certainly a misplaced pointer somewhere. The author made of not being a JS regular, my guess: missing `var` somewhere.
- watwut 13y ago
  If there is so much commented code that you can not read, delete it. If I'm not sure whether I will be putting the code back soon, no way I'm willing to dig repository history. However, commented out code is by definition free to be deleted by anybody else if it happen to be forgotten later on.
glittershark 13y ago
I always use local lightweight tag objects in git for this - if there's a commit that I'm not sure about somewhere along the line I'll tag it REVERTME or something like that.
hobo_mark 13y ago
In this day and age, why isn't there an automated way to keep file history? (like Dropbox does, but locally and with a decent interface) I am looking for something like that for Linux and my (admittedly short) research didn't turn up much.
- aryastark 13y ago
  Looked at versioning file systems? (http://en.wikipedia.org/wiki/Versioning_file_system#Linux http://en.wikipedia.org/wiki/Versioning_file_system#Linux). They've been around for awhile. Can't say why we don't have any mainstream system-level filesystem yet, though. You may also want to check out FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace http://en.wikipedia.org/wiki/Filesystem_in_Userspace). Something on top of git may already exist. If not, it wouldn't be too difficult to create something like that.
- coldtea 13y ago
  Well, OS X has such a framework built in for apps to use.
ulisesrmzroche 13y ago
The bug could have been avoided by using Handlebars comments, rather than using normal html comments.

ef4 13y ago

But that's a one-time mental cost. There's also the mental cost of navigating among all that commented code every single time you need to read that piece of source.

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 ago
  Commented-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 ago
  I 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 ago
  The 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 ago
    That'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 ago
      seems like this post should have been titled "What JavaScript(or its replacement) could learn from Haskel"

Arnor 13y ago

True, but I find commented out code really distracting while I read a file. It's really easy to use the comment method to excess and end up with a file full of old trash code. As far as Ember's issue, we didn't see the actual code. There's almost certainly a misplaced pointer somewhere. The author made of not being a JS regular, my guess: missing `var` somewhere.

watwut 13y ago
If there is so much commented code that you can not read, delete it. If I'm not sure whether I will be putting the code back soon, no way I'm willing to dig repository history. However, commented out code is by definition free to be deleted by anybody else if it happen to be forgotten later on.

glittershark 13y ago

I always use local lightweight tag objects in git for this - if there's a commit that I'm not sure about somewhere along the line I'll tag it REVERTME or something like that.

hobo_mark 13y ago

In this day and age, why isn't there an automated way to keep file history? (like Dropbox does, but locally and with a decent interface) I am looking for something like that for Linux and my (admittedly short) research didn't turn up much.

aryastark 13y ago
Looked at versioning file systems? (http://en.wikipedia.org/wiki/Versioning_file_system#Linux http://en.wikipedia.org/wiki/Versioning_file_system#Linux). They've been around for awhile. Can't say why we don't have any mainstream system-level filesystem yet, though. You may also want to check out FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace http://en.wikipedia.org/wiki/Filesystem_in_Userspace). Something on top of git may already exist. If not, it wouldn't be too difficult to create something like that.
coldtea 13y ago
Well, OS X has such a framework built in for apps to use.

ulisesrmzroche 13y ago

The bug could have been avoided by using Handlebars comments, rather than using normal html comments.