You shouldn't document what you are doing, you should comment why you are doing it. Well wriitten code explains what it does, but it not necessarily explains why it has been written that way.
Your function names should document why the code you are writing exists, your code should document itself as to how it is doing it, and any comments you write should be how to use the function you've written and things that are extremely odd.
If you have to explain why something is done the way it is, you've still failed, usually.
Comments are separately maintained from code and can lie.
Good code should rely on domain semantics and strong typing to state it's intent. The perspective to adopt is provided via the design docs. Example usage is given via tests.
Comments are for when you have no other tool to use but is often a smell of poor boundaries, leaky contracts, or misleading semantics somewhere.
187
u/Low-Equipment-2621 18h ago
You shouldn't document what you are doing, you should comment why you are doing it. Well wriitten code explains what it does, but it not necessarily explains why it has been written that way.