4 ms·

There are only four options for removing a block of code you no longer want to use: 1. Add a comment around the whole block. This may not always work, as comme

There are only four options for removing a block of code you no longer want to use: 1. Add a comment around the whole block. This may not always work, as comments within the block may need to be removed. 2. Add string delimiters before and after the block, making the block an in-place string literal. This can be broken by strings within the block. 3. Use a goto statement to skip the block. This is a pretty good method but you have to worry about the label getting moved, and fellow developers laughing at you for using goto. 4. Wrap the block with a big if (false) { }. This is the most bullet proof method, but it violates your goodness criteria.

majormajor 13y ago
Delete it and refer to your version control system's history if you need to bring it back? Edited addition to reduce the snarkiness a bit: if I see a block of dead code like that left in a file, regardless of which way it's been killed, I'm going to consider that bad unless there's a very clear comment explaining why this isn't needed anymore but was worth leaving in the code instead of fully deleting it. But if that comment's there, and the reason makes sense, it's still breaking the "rule" but becomes an example of knowing when to break the rule.
- fournm 13y ago
  Honestly, the code's probably changed enough since it was commented out to not be worth considering anymore (short of maybe leaving the comment, reworded, to explain what used to happen and why). Large amounts (I regularly see 500+ lines in a single file) of commented out code is a huge smell and it would take an outstanding justification to get me to not delete it.
Someone 13y ago
5) delete it from your code. You do have source control, so you will be able to recover the code later. If you want to leave evidence, add a comment: -- Removed Foo handling in revision ... because of ... That should be rare, though. For temporary disabling, I tend to do: const disableFooForDebugging = true if( disableFooForDebugging) That makes it easier to recognize and correct accidental checkins.
- themstheones 13y ago
  Sorry, I was attempting to be humourous. Obviously #5 is the right way to go. I can't remember ever pulling something useful out of a block of commented out code.

majormajor 13y ago

Delete it and refer to your version control system's history if you need to bring it back? Edited addition to reduce the snarkiness a bit: if I see a block of dead code like that left in a file, regardless of which way it's been killed, I'm going to consider that bad unless there's a very clear comment explaining why this isn't needed anymore but was worth leaving in the code instead of fully deleting it. But if that comment's there, and the reason makes sense, it's still breaking the "rule" but becomes an example of knowing when to break the rule.

fournm 13y ago
Honestly, the code's probably changed enough since it was commented out to not be worth considering anymore (short of maybe leaving the comment, reworded, to explain what used to happen and why). Large amounts (I regularly see 500+ lines in a single file) of commented out code is a huge smell and it would take an outstanding justification to get me to not delete it.

Someone 13y ago

5) delete it from your code. You do have source control, so you will be able to recover the code later. If you want to leave evidence, add a comment: -- Removed Foo handling in revision ... because of ... That should be rare, though. For temporary disabling, I tend to do: const disableFooForDebugging = true if( disableFooForDebugging) That makes it easier to recognize and correct accidental checkins.

themstheones 13y ago
Sorry, I was attempting to be humourous. Obviously #5 is the right way to go. I can't remember ever pulling something useful out of a block of commented out code.