[Danieru]

I suspect part of this is enforced by TA markers in university.

When marking a TA isn't trying to understand the code, they just do not have time for that. So when evaluating the documentation or comments portion of the mark they just scroll through and see how much gray is on their screen. No marks are ever deducted for bad comments.

The situation can get so silly I've had TAs complement my code and the design then deduct full documentation marks.

This has led some people I know to go over their code before submission and add worthless comments. To them "documentation" is a separate step which occurs after you've written and tested everything. The whole situation is a shame.

[glimcat]

My experience as a TA:

I never counted students off for comments, although I also never worked with a professor who had a policy of "All Code Must Be Commented Or Else." I don't think many professors did, at least not for upper-division classes. Perhaps related - most students didn't comment at all (I largely dealt with CS seniors).

Then we had a bunch of students get counted off for bugs, unimplemented features, or general weirdness in their code.

As a rule of thumb, the very few people who did comment got much better grades simply because I was allowed to give partial credit. If they at least commented what the heck they were trying to do and how, and why they thought it advanced the project - I could probably figure out what went wrong and award points accordingly.

You know that Tolstoy quote, "Happy families are all alike; every unhappy family is unhappy in its own way"?

It applies perfectly to bad code. Whether we're talking university or industry, having SOMETHING there so that your teammates or the senior developer on the team can figure out what you were TRYING to do is an enormous help.

Going comment-light is fine in a perfect world where you have concise, elegant code that works perfectly and is absolutely clear when you come back in six months and try to figure out how you structured the program and what role any particular snippet serves within the greater whole.

It's not a perfect world.

(At the same time - readability functions such that if you put a bunch of trash comments in, people reading your code will assume that most of the comments are trash. You can't just tick the box and expect that to be enough.)

[lmm]

It's not just markers at university, I've had managers who would do the same thing.

[hjnilsson]

Working as a contractor, there are often deals that mandate "100% of functions documented" or other silly stuff (I would never strike such a deal, but have inherited projects with this). Since the client actually never checks the code (only metrics) and will never pay what it would cost to create amazing documentation (which only makes sense for public APIs) we just end up with tools that automatically adds comments to functions, which means the codebase ends up with useless javadoc-like clutter.

It's the same with "100% test coverage", which is similarly abused, programmer's are a lazy bunch, and smarter than any tool that measures the quality of what they do. So forcing them doesn't work out great.

[untog]

Working as a contractor, there are often deals that mandate "100% of functions documented" or other silly stuff

I'm not so sure that's silly. It's absolutely overkill, but in a contractor/client relationship it makes sense that the client will want to make sure they have all the coverage they can get. And as a contractor you can bill for it.

[SomeCallMeTim]

I've argued my way out of TAs downgrading me because of comments, when the comments I DID have conceptually covered several lines of source code (and they were looking for a comment on each line).