Hacker News Reader

Comment by nkozyra | Hacker News Reader

Trust me, you're among friends.

You have no idea. I know git is supposed to mean I can delete code without fear of losing it.

Still...

When I comment out code, I add a timestamp of when I disabled it. Then, when I come across commented code with a timestamp more than 6 months old, I go ahead and delete it. Best of both worlds!

Oh lord.

Best demonstration of Poe's Law right here.

Doesn't "git blame" take care of your timestamps for you?

no. vc will only take care if you have the history and know what you are looking. if you publish a final version only like this all that is lost. if you run a interpreted language you can't find the place of the old code while debugging at runtime.

there are many reasons to leave code comments besides neglect. though in this case it's neglect :)

Hmm what a nice extension idea for emacs comment-dwim.

You still can put one on top of that, like this:

    #if 20141031     // Date as a valid number != 0
      // Active code
    #else
      // Inactive code
    #endif

Helps documenting experimental alternatives, even without SCM.

This is really terrible practice. You should only do this if you really have no SCM available.

I'm talking about experimental alternatives. This is not for production code. And it's still better than just out-commenting code to deactivate it.

This is a similar to an idea that David Schnepper talked about at Velocity Ignite this year.

It's only a five minute presentation but it blew me away and I'm keen to give it a try for real at some point. Video here:

https://www.youtube.com/watch?v=29UXzfQWOhQ

I like this alot, would anyone be keen to collaborate on a simple ruby gem to implement this 'tombstone' method?

great idea, I would definitely throw it into all of my ongoing projects.

I put this together today, would value any feedback and/or contributions:

https://github.com/lewispb/tombstone

Wow, simple and short, but has already given me a ton of ideas. Saved and shared with our IS department too.

Funny how this is kinda Halloween-ish.

Great share, thank you!

This is thought provoking; I shared my reactions here: http://djwonk.tumblr.com/post/101423057084/tombstones-as-a-w...

I wonder how they tombstone CSS.

I like that idea. I remove commented code when it's "old enough" but know how long it's actually been could be really helpful.

I would be awesome if there were a plugin (for your favorite text editor) for that. It should be easy to add automatically and remove when you uncomment it.

Perhaps not a bad idea. One advantage to David Schnepper's suggestion (in the video above) is that the tombstone is executable code, which can lead to metrics and even automated code removal. Buyer beware!

Glad to hear this isn't an odd concept. When I see others have commented out code in our codebase, I do a quick git blame (Sublime Git ftw!) and if it's from the previous year I'll just delete it.

We aggressively delete code. Hg/git will have it if you ever need it.

We never have.

This. Though I do often wonder how often I re-type the same thing, because I can't simply uncomment, simply because it's easier to type it out than it is to go hunting through the history. Maybe I should try to make a Git history "redone undos" script or something.

When I actually think about it I realize it's probably very nearly never. But it's hard to shake the suspicion :)

It's just more convenient to keep the code in, otherwise you'll have to look it up again which takes more time... (and effort, we're developers after all)

This was the one thing that my CS professors drilled into my head most: you have source control, why would you comment?

You only make your source control more valuable by not commenting out code; since you can then search for its presence more easily. Good advice, all around.

I think it's genetic :) Some people are "code pack rats". They're afraid to delete anything.

When you put a lot of time and effort into adding code in all the right places to provide for functional, helpful debugging, tearing it all out afterwards is just going to make you add it back in again when debugging something else down the road.

Even if you tear it out, it's way more work to try to pull it all back out, line by line, and re-implement it than to comment it out and leave the actual debugging statements in #ifdef blocks that the pre-processor will pull out anyway.

Reply on news.ycombinator.com