The general premise of the article (write more readable code) is right and should be the goal of every developer, but the conclusion (comments are bad and have to be avoided at all costs) seems a bit absolute and wrong. (But that's just my opinion)
Not getting into documentation comments (that are a completely different world to which this doesn't apply). I can think of at least one case in which comments are needed: a "complex" calculation. Sometimes we may have short functions with self-explanatory variable names, and still need a comment to explain what is going on because it may not be obvious. For example, a function that returns a mathematical calculation may need some reference/background on the calculation's logic. That comment may be longer than the function itself and there's nothing wrong with that, it may be useful for maintenance and improvements in the future.
Much appreciate your comment. As a rule of thumb i think comments can in fact be avoided at all costs and the solution lies somewhere in between
1) good naming and descriptive functions
2) small functions which follow srp
3) unit testing with good descriptions.
I have had this argument with many but usually when there was a need for a comment, one of the above weren't applied.
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.
The general premise of the article (write more readable code) is right and should be the goal of every developer, but the conclusion (comments are bad and have to be avoided at all costs) seems a bit absolute and wrong. (But that's just my opinion)
Not getting into documentation comments (that are a completely different world to which this doesn't apply). I can think of at least one case in which comments are needed: a "complex" calculation. Sometimes we may have short functions with self-explanatory variable names, and still need a comment to explain what is going on because it may not be obvious. For example, a function that returns a mathematical calculation may need some reference/background on the calculation's logic. That comment may be longer than the function itself and there's nothing wrong with that, it may be useful for maintenance and improvements in the future.
Much appreciate your comment. As a rule of thumb i think comments can in fact be avoided at all costs and the solution lies somewhere in between
1) good naming and descriptive functions
2) small functions which follow srp
3) unit testing with good descriptions.
I have had this argument with many but usually when there was a need for a comment, one of the above weren't applied.