That sounds like user documentation
Documentation of knowledge is very very usefull if you need to continue a project from someone else or start a new one, finish and modify it a year later. Good requirements is a must have. Questionable is if you are the one to create them or if the shop is large enough to have a person around to perform this tasks. I feel more and more that I need that knowledge on paper, because it now comes back as bugs and needs to get solved asap while I am working on something else. The only real problem is that documentation takes time upfront, while the problems from not having documentation is time afterwards and not visible.
Comments in code aren't always good, good comments in code are.
I've seen this extreme commenting pratice, which is not helpfull in any way. The code is full of stuff like this:
// Close the stream
Next to the extra space it takes, and all the green lines in the code it is also not very good if you refactor a lot. If I use VS refactor/rename for example, it will not modify any comments. You will end up with comments saying this does X while it actually does Y.