4 ms·
Better way: /** testCode(); testCode(); /**/ (...) /**/ productionCode(); productionCode(); /**/ I think this is better because it's
by user24 13y ago
Better way:
/**
testCode(); testCode();
/**/
(...)
/**/
productionCode(); productionCode();
/**/
I think this is better because it's much easier to see what you're supposed to do in order to switch the block on or off, and it's only a single character change per block. (though you can't switch from test to production in one character, but meh).
However, I tend to see commented code as ugly cruft. To me, comments are for explaining in natural language what you're doing, not for deactivating bits of code. If it's bad get rid of it, if it's good keep it. Why comment code?
The only time I comment out code is to warn developers away from doing something which is obvious but a bad idea, for example:
/*
// This was a neat idea but it makes it break if the user isn't logged in
userPreference = getPrefFromUserSession();
*/
- scott_w 13y agoI think a better way of doing that is to create a test that fails in exactly that condition. You can then put documentation in that test, as that's what the developer will look at first. You also get the bonus that, if someone finds a way to fix the function that causes that, then you can go back to possibly nicer code.
- user24 13y agoThat assumes TDD, but yes that would be a nice way of doing it.
- Evbn 13y agoReading tests is not TDD, it is basic due diligene when learning code. Eve still, skipping that, when the test fails, the rush coder will see the problem.
- Evbn 13y agoThis is one of the many uses for tests that too few people know.