I think a lot of this whole "code should be self-documenting" critique of comments implicitly assumes that comments are used to document WHAT the code does.
But I find generally find the most useful comments talk about WHY the code does what it does. Which the code does not do, no matter how good the variable names or the structure is. Especially in enterprise code bases with hundred of thousands of lines och code.
It is completely obvious what deleteLastRowInTableIfSecureFlagIsSet() does. But why? If the system is re-architected to no longer use secureFlag, what should happen here? If there is a bug related to the function, what is actually the correct behaviour? If we switch from SQL to a key-value store that doesn't have a "last row" what should happen?
So IMO a rule of thumb is that good code comments explain WHY, not WHAT. And in that light this whole debate misses the point.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think a lot of this whole "code should be self-documenting" critique of comments implicitly assumes that comments are used to document WHAT the code does.
But I find generally find the most useful comments talk about WHY the code does what it does. Which the code does not do, no matter how good the variable names or the structure is. Especially in enterprise code bases with hundred of thousands of lines och code.
It is completely obvious what deleteLastRowInTableIfSecureFlagIsSet() does. But why? If the system is re-architected to no longer use secureFlag, what should happen here? If there is a bug related to the function, what is actually the correct behaviour? If we switch from SQL to a key-value store that doesn't have a "last row" what should happen?
So IMO a rule of thumb is that good code comments explain WHY, not WHAT. And in that light this whole debate misses the point.