4 ms·

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 t

by lfowles 10y 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 10y 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 10y ago
  I would hire this moron, that's a good idea.
- e28eta 10y 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 10y 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 lfowles 10y ago

moron4hire 10y 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 10y ago
I would hire this moron, that's a good idea.
e28eta 10y 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 10y 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.