Just my two cents on comments (not necessarily helping you with how to document). Comments are a good thing, but only when used with discretion. I would resort to writing comments only when I think that my function is not able to convey its intents via its name, arguments and return type. Or when there are complex business logic that cannot be understood easily. Even in that case I would rely on my unit tests to serve as a documentation for my method.
I completely agree with you. The best documentation is the code itself, mostly without comments and good bunch of unit tests.
If you make any comments, they shouldn't be about the whats (the names should be clear enough to make such comments superfluous), but they should be about the whys, about intentions.
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.
Just my two cents on comments (not necessarily helping you with how to document). Comments are a good thing, but only when used with discretion. I would resort to writing comments only when I think that my function is not able to convey its intents via its name, arguments and return type. Or when there are complex business logic that cannot be understood easily. Even in that case I would rely on my unit tests to serve as a documentation for my method.
I completely agree with you. The best documentation is the code itself, mostly without comments and good bunch of unit tests.
If you make any comments, they shouldn't be about the whats (the names should be clear enough to make such comments superfluous), but they should be about the whys, about intentions.