3 ms·

This advice and the other commentary agreeing with it is surprising to me. Showing how you would have written it seems like an extremely useful part of concrete

This advice and the other commentary agreeing with it is surprising to me. Showing how you would have written it seems like an extremely useful part of concretely explaining why you don't like it. I agree that you also need to do the part where you explain why. I almost do the opposite of this advice -- refrain from criticizing unless I can show precisely how I would prefer to do it and why I think my way is better.

wickerman 7y ago
My point is that, if there's a specific reason why the code needs to be rewritten (i.e. code needs to be clearer, or more performant, or adhere to coding standards) then you can point out what's wrong with it with a simple explanation. If you just write the code "as it's meant to be" then the other person a) will not get why their code is being rejected and b) you'll be writing the code for them. Code reviews are not coding exercises. You ought to be able to explain using human language primarily. The only only instances where I've actually written code in my comments was because I was reviewing Scala code written by a very old person who had worked 20+ years in Java and it was very very difficult to get some points across - and only after several tries where he didn't get what I meant.