Doxygen attempts to fulfill that same gap, but it also suffers from trying to support every language under the sun, as well as the inherent issues of C/C++ (the use of the preprocessor to generate module boundaries does not make for fun processing). Similarly, Rust also has a widely-used builtin documentation tool (and again, the official standard library documentation is entirely the result of rustdoc).Ĭ/C++ of course don't have a builtin tool. If you've ever used, you've used the results of Javadoc. Javadoc was the first major such tool if I'm trying to use a Java library, I don't read the source code, I start by reading the generated documentation. If you look at other languages, automatically-generated code documentation has become the main way people ingest documentation for software projects. The problem isn't that no one reads generated codedoc, the problem is that doxygen is a pretty abysmal code generator. "Installing Doxygen on a project" achieves nothing, one has to write the actual docs first. So here I threw away all this noise and the theme is actively forcing the library authors to focus on important stuff in the docs, explicitly excluding useless things that could be auto-generated. Not to see stuff that's already explained by the code itself. The user should visit docs to get to know a high-level overview of a library or human-readable explanation of an algorithm. Doxygen implicitly generates useless info about what file is included by what file, list of places from where a function gets called, what line was this and that function declaration in (and where is the definition), huge class inheritance diagrams, entangled monstrous file dependency diagrams, alphabetical file index, alphabetical symbol index, including every possible undocumented symbol and file it can find and tons and tons of other stuff that has a total value of 0.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |