5 ms·

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

knodi123 12y ago
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!
- madeofpalk 12y ago
  Oh lord. Best demonstration of Poe's Law right here.
- dshap 12y ago
  Doesn't "git blame" take care of your timestamps for you?
  - gcb0 12y ago
    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 :)
- agumonkey 12y ago
  Hmm what a nice extension idea for emacs comment-dwim.
- deleted 12y ago
  [deleted]
- tempodox 12y ago
  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.
  - gpvos 12y ago
    This is really terrible practice. You should only do this if you really have no SCM available.
    - tempodox 12y ago
      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.
    - deleted 12y ago
      [deleted]
- philbo 12y ago
  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 https://www.youtube.com/watch?v=29UXzfQWOhQ
  - lewispb 12y ago
    I like this alot, would anyone be keen to collaborate on a simple ruby gem to implement this 'tombstone' method?
    - kcorbitt 12y ago
      great idea, I would definitely throw it into all of my ongoing projects.
      - lewispb 12y ago
        I put this together today, would value any feedback and/or contributions: https://github.com/lewispb/tombstone https://github.com/lewispb/tombstone
  - thebouv 12y ago
    Wow, simple and short, but has already given me a ton of ideas. Saved and shared with our IS department too.
  - ionforce 12y ago
    Funny how this is kinda Halloween-ish. Great share, thank you!
  - dj-wonk 12y ago
    This is thought provoking; I shared my reactions here: http://djwonk.tumblr.com/post/101423057084/tombstones-as-a-way-to-safely-remove-code http://djwonk.tumblr.com/post/101423057084/tombstones-as-a-w...
  - robomartin 12y ago
- phkahler 12y ago
  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.
- akirk 12y ago
  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.
  - dj-wonk 12y ago
    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!
- johnmaguire2013 12y ago
  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.
rjbwork 12y ago
We aggressively delete code. Hg/git will have it if you ever need it. We never have.
- Groxx 12y ago
  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 :)
NietTim 12y ago
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)
calinet6 12y ago
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.
budu3 12y ago
I think it's genetic :) Some people are "code pack rats". They're afraid to delete anything.
danudey 12y ago
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.

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!

madeofpalk 12y ago
Oh lord. Best demonstration of Poe's Law right here.
dshap 12y ago
Doesn't "git blame" take care of your timestamps for you?
- gcb0 12y ago
  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 :)
agumonkey 12y ago
Hmm what a nice extension idea for emacs comment-dwim.
deleted 12y ago
[deleted]
tempodox 12y ago
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.
- gpvos 12y ago
  This is really terrible practice. You should only do this if you really have no SCM available.
  - tempodox 12y ago
    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.
  - deleted 12y ago
    [deleted]
philbo 12y ago
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 https://www.youtube.com/watch?v=29UXzfQWOhQ
- lewispb 12y ago
  I like this alot, would anyone be keen to collaborate on a simple ruby gem to implement this 'tombstone' method?
  - kcorbitt 12y ago
    great idea, I would definitely throw it into all of my ongoing projects.
    - lewispb 12y ago
      I put this together today, would value any feedback and/or contributions: https://github.com/lewispb/tombstone https://github.com/lewispb/tombstone
- thebouv 12y ago
  Wow, simple and short, but has already given me a ton of ideas. Saved and shared with our IS department too.
- ionforce 12y ago
  Funny how this is kinda Halloween-ish. Great share, thank you!
- dj-wonk 12y ago
  This is thought provoking; I shared my reactions here: http://djwonk.tumblr.com/post/101423057084/tombstones-as-a-way-to-safely-remove-code http://djwonk.tumblr.com/post/101423057084/tombstones-as-a-w...
- robomartin 12y ago
phkahler 12y ago
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.
akirk 12y ago
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.
- dj-wonk 12y ago
  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!
johnmaguire2013 12y ago
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.

rjbwork 12y ago

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

Groxx 12y ago
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 :)

NietTim 12y ago

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)

calinet6 12y ago

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.

budu3 12y ago

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

danudey 12y ago

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.