4 ms·

> Most developers don't like getting rid of stuff. They want to keep chunks of code around in case they need them again. Really? I LOVE being able to delete st

by vlunkr 11y ago

> Most developers don't like getting rid of stuff. They want to keep chunks of code around in case they need them again. Really? I LOVE being able to delete stuff.

rfreytag 11y ago
I think git has made it easier to clean up code secure in the knowledge that we really can get the old code back in all its crufty glory if we really must.
- slavik81 11y ago
  The people downvoting this probably haven't worked with version control systems in which it's actually really difficult to get the old versions of files. You'd think that it would always be easy, but you would be wrong. I used to use AccuRev, and it had a number of real problems in bringing back old code. Retrieving old code was possible, but required creating 'history streams' on the project and you basically had to do a whole new checkout into a new workspace. The commands that worked with history were also sometimes rather sketchy. There was always a question 'will a revert actually succeed?' It was much safer to manually undo changes. I never realized how painful it was to retrieve old code in that system, because I simply never bothered to do so. We designed our workflows around not having to do that. When I first learned git and discovered you could just grab an old file with git checkout <revision> -- <filename> I was shocked. I'd never really thought about my version control system before. I just used what I was given. But, at that moment, I realized that I'd been working with a terrible system for years.
  - taneq 11y ago
    Which version control systems are these? All the usual suspects make this easy - in fact I find git to be somewhat more difficult than other simpler tools like cvs or svn. Even (shudder) Visual SourceSafe offers this functionality.
    - adrianN 11y ago
      There are still version control systems around that don't have the concept of a commit of multiple files, Rational ClearCase for example. So if your change involves multiple files, undoing it requires remembering which files where involved and undoing each one separately. That's quite a pain, especially if you delete whole files that you want to have back.
      - kruczek 11y ago
        Yep, especially since ClearCase records adding/removing files not only as a change to these files themselves, but also as a completely separate change to the parent directory. Really terrible system.
- deleted 11y ago
  [deleted]
lfowles 11y ago
I love being able to delete redundant stuff, but I have to admit, there are a few commented out but not deleted lines in my code! //If service reverts to this behavior, this is the spot where $ESOTERIC_CALL should be.
- moron4hire 11y ago
  I prefer to leave that sort of stuff behind an `if(false)` block, so that the compiler or linter can reach it and check it (and ultimately optimize it away, so I get the best of both worlds). Actually, I prefer to just throw it away and worry about figuring it out again later if it becomes an issue again. I don't have the problem of not being able to figure out how to do things again and needing to look back at old code. But if someone I'm working with absolutely insists, then I use the `if(false)` block.
  - lfowles 11y ago
    I would hire this moron, that's a good idea.
  - e28eta 11y ago
    I don't like that solution, because you either don't have the compiler warning for unused/dead code turned on, or you're ignoring it. My preference is definitely for deletion. I suppose in C languages the "better" variant would be an "#if false" pre compiler directive.
    - moron4hire 11y ago
      No, that is not better, because it removes the code before getting to the static checker. Most compilers can optimize dead code away automatically, at least the ones for sane languages that understand they are there to serve the programmer and not the other way around. Dead code checking is one of the last checks an optimizing compiler does, in the hopes that other optimizations have made sections of code dead (things like inlining constant expressions need to happen first). So I still want this code to be checked, in case any dependencies it has change. But ultimately it still goes away. Frankly, I don't even want the cognitive load of dead code, so as I said, I only do this for people who insist they need this sort of crutch.

by vlunkr 11y ago

> Most developers don't like getting rid of stuff. They want to keep chunks of code around in case they need them again. Really? I LOVE being able to delete stuff.

rfreytag 11y ago

I think git has made it easier to clean up code secure in the knowledge that we really can get the old code back in all its crufty glory if we really must.

slavik81 11y ago
The people downvoting this probably haven't worked with version control systems in which it's actually really difficult to get the old versions of files. You'd think that it would always be easy, but you would be wrong. I used to use AccuRev, and it had a number of real problems in bringing back old code. Retrieving old code was possible, but required creating 'history streams' on the project and you basically had to do a whole new checkout into a new workspace. The commands that worked with history were also sometimes rather sketchy. There was always a question 'will a revert actually succeed?' It was much safer to manually undo changes. I never realized how painful it was to retrieve old code in that system, because I simply never bothered to do so. We designed our workflows around not having to do that. When I first learned git and discovered you could just grab an old file with git checkout <revision> -- <filename> I was shocked. I'd never really thought about my version control system before. I just used what I was given. But, at that moment, I realized that I'd been working with a terrible system for years.
- taneq 11y ago
  Which version control systems are these? All the usual suspects make this easy - in fact I find git to be somewhat more difficult than other simpler tools like cvs or svn. Even (shudder) Visual SourceSafe offers this functionality.
  - adrianN 11y ago
    There are still version control systems around that don't have the concept of a commit of multiple files, Rational ClearCase for example. So if your change involves multiple files, undoing it requires remembering which files where involved and undoing each one separately. That's quite a pain, especially if you delete whole files that you want to have back.
    - kruczek 11y ago
      Yep, especially since ClearCase records adding/removing files not only as a change to these files themselves, but also as a completely separate change to the parent directory. Really terrible system.
deleted 11y ago
[deleted]

lfowles 11y ago

I love being able to delete redundant stuff, but I have to admit, there are a few commented out but not deleted lines in my code! //If service reverts to this behavior, this is the spot where $ESOTERIC_CALL should be.

moron4hire 11y ago
I prefer to leave that sort of stuff behind an `if(false)` block, so that the compiler or linter can reach it and check it (and ultimately optimize it away, so I get the best of both worlds). Actually, I prefer to just throw it away and worry about figuring it out again later if it becomes an issue again. I don't have the problem of not being able to figure out how to do things again and needing to look back at old code. But if someone I'm working with absolutely insists, then I use the `if(false)` block.
- lfowles 11y ago
  I would hire this moron, that's a good idea.
- e28eta 11y ago
  I don't like that solution, because you either don't have the compiler warning for unused/dead code turned on, or you're ignoring it. My preference is definitely for deletion. I suppose in C languages the "better" variant would be an "#if false" pre compiler directive.
  - moron4hire 11y ago
    No, that is not better, because it removes the code before getting to the static checker. Most compilers can optimize dead code away automatically, at least the ones for sane languages that understand they are there to serve the programmer and not the other way around. Dead code checking is one of the last checks an optimizing compiler does, in the hopes that other optimizations have made sections of code dead (things like inlining constant expressions need to happen first). So I still want this code to be checked, in case any dependencies it has change. But ultimately it still goes away. Frankly, I don't even want the cognitive load of dead code, so as I said, I only do this for people who insist they need this sort of crutch.