6 ms·

" but at some point I decided that the widget was no longer needed, so I commented out the widget's markup" SOURCE CONTROL, DO YOU SPEAK IT? In all seriousnes

• astrodust 13y ago
  Exactly. If you're committing large sections of code that are commented out you're doing it wrong.
• oinksoft 13y ago
  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.
• mightybyte 13y ago
  I can't even fathom this mindset. Deleting the code and relying on source control removes the issue from top of mind. Also, it will require more work to bring back later. Both of these are very good reasons to temporarily keep commented code around.
  • JoshTriplett 13y ago
    > Deleting the code and relying on source control removes the issue from top of mind. That's the goal. Your top of mind is very limited; use tools like version control to help you conserve it. > Also, it will require more work to bring back later. Then you need better version control. You can either grab the reverse diff from the commit removing it and apply that (possibly with conflict resolution against more recent changes), or just grab the original file and copy the block of code out of it.
    • taude 13y ago
      This assumes that you knew that the code was once there, and where it was. Working on a team with partially implemented features with planned future hooks, it's just easier to keep the intent in the live code (hopefully with some good comments/docs)
      • mattmanser 13y ago
        Your half-implemented feature will never, ever make it into live code. Ever. Just delete it, you commented out code leaving scum. We all hate you. And you smell. But seriously. Never commit commented out code. It's a cardinal sin and massive code smell. Never leave YAGNI, but maybe one day, hooks in code. Just delete it. It will never make it live and when someone actually comes to do that feature they'll usually half finish the feature before they even find your code, and then won't be 100% sure your code is supposed to do exactly the same feature and so they won't delete your cruft as they don't really know what on earth it's supposed to do. And on top of that your code won't work because it hasn't been refactored along with all the live code, so all the property names are wrong, it references methods with signatures that have changed and probably even the names of the classes have changed.
• danielweber 13y ago
  I agree that keeping commented-out source around is bad, but commented-out source should really not affect program behavior. The typical way of testing the removal of something is to comment it out, see the results, and if you like them you delete it and then commit.
• thatthatis 13y ago
  I was expecting an ember vs angular holy war in the comments, not a when-to-comment-out-vs-delete holy war.
  • mattgreenrocks 13y ago
    It's an easier argument than purity-vs-no-purity.
  • camus2 13y ago
    Ember vs angular ,it's so 2013...
• hodgesmr 13y ago
  While you're not wrong, this doesn't speak at all to the issue that the OP is expressing. While you might think his/her style is messy, it should still be valid. Commented-out code should behave the same way as deleted code.
  • ef4 13y ago
    > Commented-out code should behave the same way as deleted code. But it did, that's not the problem the author encountered. The issue wasn't that commented code caused a behavior change, it's that uncommented-but-assumed-unused code caused a behavior change. The only thing that got commented out was the markup that originally invoked said code.
• pjmlp 13y ago
  I hate it as well. I do know quite a few people that do it all the time.
• daigoba66 13y ago
  I compleletly agree. But I will add that another solution is to keep the code alive, but wrapped in a conditional with a feature flag. This is not always a good alternative to just deleting code, but it can be a good alternative to commenting-out a block of code or using compiler directives.
• danneu 13y ago
  I hear this sentiment a lot, and I at least understand the sort of purity of deleting code instead of commenting it out, but that's the only value it seems to bring whenever I try it. Scrubbing back into history (or remembering that there's even something to scrub back to) doesn't seem to ever be as convenient for me as it is for people that are peeved by commented out code. I'm not that great at Git, but I'm also not trawling through history very frequently and there still seems to be a mental overhead associated with it compared to seeing some commented code a few lines away. The article goes on to say: > I wasn't sure whether we would ultimately keep the > widget or not, so I opted to keep the above > javascript code for the controller and view around > for awhile so it would be easily available if I > later decided to re-enable that UI element. That seems reasonable to me. In a file I was just working on before I decided to habitually check HN, I have two past versions of a function commented out above the final revision of the function. Next to each older revision, I've annotated some reasons why they were revised. When I continue to work on this function a week from now, I'm reminded of my efforts so far. Someone would probably say that those annotations should be moved into commit messages and the git log should tell the story about this function. But all that really seems to do is disperse my notes about this function across intermittent entries into this file's commit history. And once those past revisions are deleted from the current view of the file, I certainly won't remember that those notes exist for me to scrub back to in the first place. - How do you manage this kind of stuff? - What's your workflow for looking for and fetching deleted code?
  • andrewingram 13y ago
    At work, our approach is to simply not allow commented out code to get through code review. It allows individual developers to comment out blocks, and even commit those comments if they so desire, but they never make it into master.
• masklinn 13y ago
  OTOH, finding removed code in your history is still a pain in the ass, unless commit messages are well and clearly crafted (which they usually aren't, and even then the keywords you search for may not be those you committed under). VCS may need to grow a "full history" blame, which displays all hunks removed from the file.
• thijsc 13y ago
  Funny talk on this subject: http://www.youtube.com/watch?v=Oj4vXMRenFo http://www.youtube.com/watch?v=Oj4vXMRenFo
• whatevsbro 13y ago
  > SOURCE CONTROL, DO YOU SPEAK IT? So you're saying you're an Ember.js user, huh?