5 ms·

Code doesn’t usually exist in a vacuum; it has dependencies on an environment that keeps moving forward. If your old commented-out code is calling any function

Code doesn’t usually exist in a vacuum; it has dependencies on an environment that keeps moving forward. If your old commented-out code is calling any functions, those functions may have changed. It probably used a bunch of libraries. It probably needed a certain compiler or interpreter version. And if it ran on just one OS or hardware, you might have a hard time even finding the right system to run the old code. In other words, unless you are also keeping your entire universe in revision control (all code changes, lists of program and library versions, old machines, etc.), then there isn’t much point in just preserving code. That code probably won’t copy/paste into the current environment with the same behavior, and it’s almost worse if it does “fit” because the behavior may now be misleading.

js8 10y ago
I disagree. It's sometimes useful to preserve commented out code just because it represents some idea. (This is actually case of the example from the article.) You can always look into historical source for context, but it's impossible to search source for something you don't know exists. (I kinda like the trick with reference to commit, but these become even more mysterious over many years, unfortunately, since the commit numbers can get lost.) Now if the idea behind the code itself becomes obsolete, you can always delete it. Although working on a 30-year old code bases (without any unit tests) taught me that I should never delete things unless I fully understand why they are there. Perhaps we could acknowledge that there should be a different set of practices for working with 1-year old code and 30-year old code.
- knocte 10y ago
  > It's sometimes useful to preserve commented out code just because it represents some idea. Then put a fucking comment saying this: "this commented out code below is to preserve idea FOO". Leaving commented out code without a real comment is just showing how unprofessional you are (or how you want to keep your job by trying to keep a knowledge-silo in your head).
  - js8 10y ago
    I don't disagree with that, it's exactly what I would do, and it's shown in the example in the article, too.
- collyw 10y ago
  I often want to delete what seems to be obsolete code, but I am never sure it is going to break something somewhere done the line. My tactic these days is top comment it out, put a data and explanation next to it. If i come across the same commented out code a while later then I can safely delete it.

js8 10y ago

I disagree. It's sometimes useful to preserve commented out code just because it represents some idea. (This is actually case of the example from the article.) You can always look into historical source for context, but it's impossible to search source for something you don't know exists. (I kinda like the trick with reference to commit, but these become even more mysterious over many years, unfortunately, since the commit numbers can get lost.) Now if the idea behind the code itself becomes obsolete, you can always delete it. Although working on a 30-year old code bases (without any unit tests) taught me that I should never delete things unless I fully understand why they are there. Perhaps we could acknowledge that there should be a different set of practices for working with 1-year old code and 30-year old code.

knocte 10y ago
> It's sometimes useful to preserve commented out code just because it represents some idea. Then put a fucking comment saying this: "this commented out code below is to preserve idea FOO". Leaving commented out code without a real comment is just showing how unprofessional you are (or how you want to keep your job by trying to keep a knowledge-silo in your head).
- js8 10y ago
  I don't disagree with that, it's exactly what I would do, and it's shown in the example in the article, too.
collyw 10y ago
I often want to delete what seems to be obsolete code, but I am never sure it is going to break something somewhere done the line. My tactic these days is top comment it out, put a data and explanation next to it. If i come across the same commented out code a while later then I can safely delete it.