Lol. That’s why we comment with “why”, rather than “what”. The answer to “what the duck where we even thinking?” usually doesn’t need updated until the commented code goes away.
Never understood this argument, it’s the person’s responsibility who changed the code to update the comments if needed. Otherwise they just implicitly admit that they did not read it or understand the context, or just plain did not care.
Stage 2, “why does this code have nothing to do with the very detailed comments?”
Always comment the why, not the what/how. Bonus of doing this is you only need to update the comments when the why changes
git blameIf the comments don’t match the code then someone failed to properly review it.
Lol. That’s why we comment with “why”, rather than “what”. The answer to “what the duck where we even thinking?” usually doesn’t need updated until the commented code goes away.
Never understood this argument, it’s the person’s responsibility who changed the code to update the comments if needed. Otherwise they just implicitly admit that they did not read it or understand the context, or just plain did not care.
It just never works. Its important documentation breaks if changes are made. The best docs are baked into unittests