For my current job we’ve all agreed to take the approach of not writing comments that say what the code does, but why you did something the way you did. Probably about 90% of our code is uncommented because it just doesn’t need to be, but every once in a while you have to do something out of the ordinary to get the desired behavior, and explaining why you made the weird decision you did is infinitely more helpful.
This exactly. I love this approach to commenting and use it all the time. I also like to write doc-comments wherever possible; it’s saves time and makes working on an unfamiliar part of the codebase much easier.
For my current job we’ve all agreed to take the approach of not writing comments that say what the code does, but why you did something the way you did. Probably about 90% of our code is uncommented because it just doesn’t need to be, but every once in a while you have to do something out of the ordinary to get the desired behavior, and explaining why you made the weird decision you did is infinitely more helpful.
This exactly. I love this approach to commenting and use it all the time. I also like to write doc-comments wherever possible; it’s saves time and makes working on an unfamiliar part of the codebase much easier.