I read an article way back on what to comment. I don't comment on what my code is doing. I comment only two things.
One is the general structure of the whole project without giving any specific implementation details (only talking abstractions).
And the second thing I comment is why I decided to go a particular way to solve a problem. Suppose there is a bug or a new feature to develop. I would do my research and mostly find I can solve it in multiple ways. I just leave a small summary of my research and the links I read from and also a reason why I'm choosing one method over another.
IMO what code is doing should be self-explanatory via naming of functions and variable names. Comments should answer questions code cannot.
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 read an article way back on what to comment. I don't comment on what my code is doing. I comment only two things.
One is the general structure of the whole project without giving any specific implementation details (only talking abstractions).
And the second thing I comment is why I decided to go a particular way to solve a problem. Suppose there is a bug or a new feature to develop. I would do my research and mostly find I can solve it in multiple ways. I just leave a small summary of my research and the links I read from and also a reason why I'm choosing one method over another.
IMO what code is doing should be self-explanatory via naming of functions and variable names. Comments should answer questions code cannot.