[wott]

> If the code in question is part of the pkg/module/crate/whatever's API, aka. someone else may have to use it some day, it should be commented regardless of how complex it is.

No, the API should be documented, which is orthogonal to the presence or absence of comments inside the code.

[usrbinbash]

That depends entirely on the toolset available.

Languages like Java, Python or Golang enable inline documentation which can then be used by standardized tools (Javadoc, Docstrings, Godoc).

eg.

https://pkg.go.dev/flag@go1.17.6#PrintDefaults

The entire documentation of this function (including HTML) is generated by the Godoc tool reading comments which conform to a certain convention.

https://cs.opensource.google/go/go/+/refs/tags/go1.17.6:src/...

There is literally no downside to this. The code and its documentation are in the same file, its much simpler for developers to update it when there is a change, and its easy to generate documentation directly from source on the fly.

[denton-scratch]

Agree. I suspect the difference of opinion might be down to systems like Javadoc, that transform code comments into API docs. But Javadoc comments are often auto-generated from function prototypes, which results in Javadoc comments that add nothing to the raw code except bloat. I don't think I'ver ever seen good documentation produced from doc-comments.

There's another thread on the front page about literate programming; I suspect that doc-comments amount to an effort to weave code and documentation together, in a knuthian manner, to kind-of automate literate programming. It doesn't work, AFAICS. You get bloated code and bad docs.

[marcos100]

Love your comment.

doc-comments are good because it explains well what the class/method/whatever are there for, sometimes with examples, that helps understand the code.

But I hate that they use so much space inside the source code that I have to scroll hundreds of lines to read the code. And those doc-comments are filled with markup that makes it harder to read.

I would like a literate a system that generates source code that is well formatted and where the only comments are what the function does and some inner function comment where the code is complex. Every other lengthy and detailed description should be inside the produced pdf/html.