Say you start work on a new code base. Would you, as a user, rather have 90% or 10% of its API functions commented with Doxygen or something similar?
Using my psychic powers I suspect that you chose 90%.
It seems like the obvious thing. Lots of companies even have a mandate that all API functions (or >90% of them) must be documented. Not having comments is just bad. This seems like a perfectly obvious no-brainer issue.
But is it really?
Unfortunately there are some problems with this assumption. The main one being that the comments will be written by human beings. What they probably end up being is something like this.
* Takes a foobar and frobnicates it.
* @param f the foobar to be frobnicated.
* @param strength how strongly to frobnicate.
* @return the frobnicated result.
int frobnicate_foobar(Foobar f, int strength);
This something I like to call documentation by word order shuffle. Now we can ask the truly relevant question: what additional information does this kind of a comment provide?
The answer is, of course, absolutely nothing. It is only noise. No, actually it is even worse: it is noise that has a very large probability of being wrong. When some coder changes the function, it is very easy to forget to update the comments.
On the other hand, if only 10% of the functions are documented, most functions don’t have any comments, but the ones that do probably have something like this:
* The Foobar argument must not have been initialized in a different
* thread because that can lead to race conditions.
int frobnicate_foobar(Foobar f, int strength)
This is the kind of comment that is actually useful. Naturally it would be better to check for the specified condition inside the function but sometimes you can’t. Having it in a comment is the right thing to do in these cases. Not having tons of junk documentation makes these kinds of remarks stand out. This means, paradoxically, that having less comments leads to better documentation and user experience.
As a rough estimate, 95% of functions in any code base should be so simple and specific that their signature is all you need to use them. If they are not, API design has failed: back to the drawing board.