Write self-documenting code, don't write comments.
What is so bad about comments? Well, you have no proof if the comment and the code are in sync. Or you have comments which documenting the obvious. When you check in code into the repository, some statical code analysis will maybe reject your commit/push if the code is wrong but no analysis tool will reject your commit/push if the comments say nothing about the code.
Imagine this situation: Someone gets the task to update a function which currently generates two different outputs, and his task is to add a third output type. He changes the code and makes the code pass all tests. He checks in the code into the repository - but he forgot about the comment and didn't update it. Some months later a bug has been reported - an output has a wrong type, and it's your task to fix the bug. While debugging, you find this function and its old comment. The comment mentions two output types, the code clearly lists three. The bug report is about a wrong output type. What a dilemma. Have you found the correct function? Can you trust any comment now? Do you fix the bug and comment?
Don't document every code instead, document only when the code must be cryptic to achieve the desired behavior - think of C developers using ASM code to speed up this one loop. Instead, try to write self-documenting code. Here is an excellent blog post about it -> sitepoint.com/self-documenting-javascript by Jani Hartikainen