Wow. Every line.
There is such a thing as too many comments or too liberal use of comments in code.
APL/J are highly compressed and any reasonable explanation would require more than one line of documentation per line of code. I know there's some J in financial institutions.
For most code it will be overkill but there are some companies where it's integral for core systems.
I would love to work in a place where documentation was cosidered a valuable asset, but I think that your example is off mark.
The best rule of thumb is, make the code so clear that it is itself a comment, and only if the code cannot relay the meaning, then add a comment.
on the other hand, if it was named something like number_of_records it would be clearer.
That’s only true if comments are kept up-to-date. More often than not, they get out of sync with the code itself, causing even more confusion.
The best case scenario I found was in a bank. Each line of code was documented and rationale explained in plain english. This way hypothetically even a newbie could run the system.
While different places have different issues, I found that the quality of documentation was inversely proportional to people's insecurity about their job. More insecure they were about their job. More resistance to documentation was found.