On Wed, Sep 26, 2018 at 11:34:04PM -0700, Jonathan Nieder wrote: > > We already have the /** convention I mentioned above. Could we have > > another micro-format like: > > > > /** API:strbuf - working with strings */ > > > > in each header file? That would make generating such an index pretty > > trivial. > > Can you spell out the problem for me a little more? E.g. if we had a > convention that the first comment in strbuf.h should say > > /* strbuf - Git's standard string type */ > > or even just > > /* Git's standard string type */ > > would that do the trick? I assumed that not all header files would want to advertise themselves as a public API, so we'd want to some way to differentiate these from first comments in "other" header files (and I assumed we did not want a separate list of "these are the API files to go into the index", at which point you might as well just write "standard string type" in that list). But I'm happy with any convention that lets Ævar generate the index he wants. > > Interesting. I'm not totally opposed to putting the documentation > > alongside the actual code. It does feel a bit cluttered to me, but I > > think you're right that it keeps everything as close together as > > possible. > > I've experienced projects following both conventions. One thing I like > a lot about documentation in the header file is that it encourages > people to make the API documentation self-contained. That is, you > describe the contract in a way that doesn't require reading the > implementation for details. > > It took me a while to get used to this kind of convention but now I > really like it. So I really do prefer to keep putting API > documentation in the header files in Git. (Implementation > documentation in the source files is of course also very welcome.) Yeah, I'd agree with all of that. > I use kythe to get an outline view of the header files. Looks neat. Doesn't seem to be package for Debian, though. ;) > In Debian we just ship all the docs. For something like > technical/pack-heuristics, it's quite nice. For the API docs, I think > they belong in the headers. Yes, I'd agree with that. About half of technical/* is design docs, etc, that might be of use to random folks. But the internal code APIs are really only useful if you have an actual clone of git.git. -Peff
