Doxygen, a document generator mainly for C++
An alternative to Javadoc is Doxygen. Doxygen works highly similarly to Javadoc, except that it can process more languages (Java, C++, C#, and more). Doxygen is most commonly used with C++. Additionally, there’s a GUI tool called Doxywizard that makes it easy to generate the file.
Download Doxywizard
The Doxygen download also includes Doxywizard. See the Doxygen Downloads page for more download links.
Here’s the Doxywizard front-end GUI generator:
Here’s the Doxygen output:
You don’t need to use the wizard. You can also generate Doxygen through a configuration file, which is typically how developers run Doxygen builds from a server.
In contrast to Javadoc, Doxygen also allows you to incorporate external files written in Markdown. And Doxygen provides a search feature. These are two features that Javadoc lacks.
Doxygen is maintained by a single developer and, like Javadoc, hasn’t changed much over the years. In my opinion, the interface is highly dated and somewhat confusing. But C++ developers will be accustomed to it.
Integrating builds automatically
In a lot of developer shops, document generators are integrated into the software build process automatically. Doxygen allows you to create a configuration file that can be run from the command line (rather than using the frontend GUI). This means when developers build the software, the reference documentation is automatically built and included in the output.
Other document generators
You don’t need to limit yourself to either Javadoc or Doxygen. There are dozens of different document generators for a variety of languages. Just search for “document generator + {programming language}” and you’ll find plenty. However, don’t get very excited about this genre of tools. Document generators are somewhat old, produce static front-ends that look dated, are often written by engineers for other engineers, and not very flexible.
Perhaps the biggest frustration of document generators is that you can’t integrate the rest of your documentation with them. You’re mostly stuck with the reference doc output. You’ll also need to generate your how-to guides and other tutorials, and then link to the reference doc output. As such, you won’t end up with a single integrated experience of documentation. Additionally, it will be hard to create links inline within topics between the two outputs. Fragmentation of outputs is a topic I explore with more detail in Integrating Swagger UI with the rest of your docs.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.
129/166 pages complete. Only 37 more pages to go.