Hacker News Reader

Comment by al2o3cr | Hacker News Reader

" 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 seriousness, this is a major peeve of mine - the time that you're most confident that code can be deleted is when you're removing the pieces that depend on it. If the deletion really turns out to be wrong, you should be able to restore the code from source control. If you can't, stop using broken source control.

Leaving leftover dreck in your source files "just in case" is like stashing your leftover sandwich crumbs in your pocket at lunch. Clean up your mess!

View on HN

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.

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.

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).

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.

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.

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.

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.

seems like this post should have been titled "What JavaScript(or its replacement) could learn from Haskel"

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.

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.

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.

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.

Looked at versioning file systems? (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). Something on top of git may already exist. If not, it wouldn't be too difficult to create something like that.

Well, OS X has such a framework built in for apps to use.

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

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.

> 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.

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)

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.

Haaa....I hate me, too.

Seriously, though, we do it all the time. Successfully. We even write skeleton code, and have other people finish it off, or take the half-baked idea and implement it properly. Sometimes in this sprint, sometimes in the next. We tend not to let these things stagnate though, so if the spec changes, the ideas are usually ripped out along with them. A lot of the cruft eventually comes out during code reviews...

It's definitely an anti-pattern, using one's code base to communicate....but the right team with the right processes, can work for the short-term. (short-term vs long-term is probably the key here)

This wasn't a half-implemented feature. It was a fully implemented and debugged feature. I was experimentally removing it in favor of a different approach and didn't want to have to go dredging through source control or reinvent and debug it later if I decided we needed it.

"dredging"? It sounds like you aren't very familiar with your tools. Commit, delete the code, commit. Now you're a rollback/backout away from getting it back.

> Your top of mind is very limited; use tools like version control to help you conserve it.

Seeing a commented block scroll by doesn't waste top of mind. And if you really don't want to see it editors have something called code folding.

> Then you need better version control.

Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile back, but you can't remember enough details about to come up with a good search term? No matter how good your version control is that's going to be a tough proposition.

Tag commits which delete things you suspect you may want to restore later with a descriptive name and message. Occasionally go back and prune those tags when you have nothing better to do.

Yes, be a full-time source control maintainer instead of programming...

> Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile back, but you can't remember enough details about to come up with a good search term?

I find that a `author(..) and file(..)` (hg) query gets you at least 90% of the way there if you have things split into a reasonable number of files. From there, running through a few guesses about search terms or even scanning the commit messages is pretty feasible. Date ranging can help, too.

There's so much data in source control - don't navigate by just commit messages.

I was expecting an ember vs angular holy war in the comments, not a when-to-comment-out-vs-delete holy war.

It's an easier argument than purity-vs-no-purity.

Ember vs angular ,it's so 2013...

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?

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.

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.

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.

> 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.

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.

Exactly. If you're committing large sections of code that are commented out you're doing it wrong.

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.

Funny talk on this subject: http://www.youtube.com/watch?v=Oj4vXMRenFo

I hate it as well. I do know quite a few people that do it all the time.

> SOURCE CONTROL, DO YOU SPEAK IT?

So you're saying you're an Ember.js user, huh?

Reply on news.ycombinator.com