> If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function. That's the usual argument, and

> If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function. That's the usual argument, and the counter-argument is always the same: you shouldn't comment the what (though I'll argue there's always exceptions), you should comment the why. Why are you doing this processing here rather than there? Why do you not apply the usual pattern in this specific case? Why does this code, that will make you want to refactor, has been written like this?