Closed. This question is opinion-based. It is not currently accepting answers.
Closed 7 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
My team is starting to document our C code using doxygen, paying particular attention to our public API headers. There appears to be a lot of flexibility and different special commands in doxygen, which is great, but it's not clear what's a good thing and what's a bad thing without trial and error.
What are your favourite ways to mark up your code, what are your MUST DOs and DO NOTs?
Please provide your top tips, one per answer to facilitate voting.
I am looking to define our whole approach to API documentation, including providing a template to get the rest of the team started. So far I have something like this:
/**
* #file example_action.h
* #Author Me (me#example.com)
* #date September, 2008
* #brief Brief description of file.
*
* Detailed description of file.
*/
/**
* #name Example API Actions
* #brief Example actions available.
* #ingroup example
*
* This API provides certain actions as an example.
*
* #param [in] repeat Number of times to do nothing.
*
* #retval TRUE Successfully did nothing.
* #retval FALSE Oops, did something.
*
* Example Usage:
* #code
* example_nada(3); // Do nothing 3 times.
* #endcode
*/
boolean example(int repeat);
You don't need and should not write the name of the file in the #file directive, doxygen reads the name of the file automatically. The problem with writing the name of the file is that when you rename the file you will have to change the #file directive as well.
Providing #author and #date information is also useless most of the time since the source control system does it a lot better than someone editing the files manually.
You also don't have to write #brief if you use the following Doxygen syntax and enable JAVADOC_AUTOBRIEF in doxygen's configuration:
/*! Short Description on the first line
Detailed description...
...
*/
void foo(void) {}
The #name directive for functions is also 100% redundant most of the time and completely useless. It only brings errors when someone modifies the name of the function and not the doxygen #name.
Write a descriptive home page using #mainpage (in a separate header file just for this purpose). Consider, as shown in my example, making it a guide to your main classes/functions and modules.
Another Sample
Whilst I was getting the above-linked main oofile doxygen content back online, here's an example from some current client work using Markdown format. Using Markdown you can refer to a mainpage in markdown (in the Doxygen settings) which is great for the typical readme.md file included in open-source projects.
Lingopal
========
Developer Documentation started when Andy Dent took over support in May 2014.
There are a number of pages in Markdown format which explain key aspects:
- #ref doc/LingopalBuilding.md
- #ref doc/LingopalSigning.md
- #ref doc/LingopalDatabases.md
- #ref doc/LingopalExternals.md
See the Related Pages list for more.
-------------
_Note_
These pages, whilst readable by themselves, are designed to be run through the [Doxygen](http://www.doxygen.com) code documentation engine which builds an entire local cross-referenced set of docs. It uses a minor [extension of Markdown formatting.](http://www.stack.nl/~dimitri/doxygen/manual/markdown.html)
The settings to generate the documentation are `Lingopal.doxy` and `LingopalDocOnly.doxy`. The latter is used for quick re-generation of just these additional pages.
Use Groups to organise your code into modules.
Remember that you can put almost everything into multiple groups so they can be used to provide semantic tagging like the tags in Stack Overflow. For example, you might tag things as specific to a given platform.
You can also use groups to match a folder hierarchy within an IDE, as shown in my RB2Doxy sample output.
Groups work well when nested - I have a large example for the OOFILE source.
Some commands i use in my code :
\todo { paragraph describing what is to be done } Useful to keep track of todos, a page will be created in final documentation containing your todo list.
\c <word> Displays the argument using a typewriter font. Use this to refer to a word of code. I would use it before "TRUE" and "FALSE" in your example.
\a , \warning , \see : see http://www.stack.nl/~dimitri/doxygen/commands.html#cmdc for description
A good "best practice" (though not always achievable) is to provide short, working examples for every API, and pull them into the help using \includelineno (or \include for no line numbers). These can be unit tests, if they're written so users can understand them (ie, not hooked into a larger test harness). As a nice side effect, changes to the API will break the samples, so they have to be kept up to date.
You can describe an API in words, but there's nothing like seeing the actual code to understand how to use it.
As I find myself editing code on higher-resolution screens I've moved from using the backslash to the # prefix on Doxygen commands. Not so noisy backslash has found itself now too damned hard to make out the Doxygen commands.
If you are sure your team will follow such a heavyweight template, fine, use it as shown.
Otherwise, it looks like JavaDoc. One of the nice things about Doxygen is how good a job it does without having to use use such strong markup. You don't need to use #name and with the JAVADOC_AUTOBRIEF setting you can skip #brief - just make sure the first line of the comment is a reasonable brief description.
I prefer descriptive names over enforcing documentation and encouraging people to add comments only when they add significant value. That way, the valuable comments aren't drowned out by all the noise.
If you have bugs located in the code or you find bugs you can also tag in the code like this:
/** #bug The text explaining the bug */
When you then run doxygen you get a seperate Bug List alongside lists like Todo List
If you have a really, really big project -- big enough that Doxygen runs take over an hour -- you can cut it up into multiple modules that Doxygen later links together using tag files.
For example, if you have a big MSVC solution with twenty projects in it, you can make directory be its own Doxygen run, and then use tag-files to glue together the output the same way a linker glues together .libs to make an executable.
You can even take the linking metaphor more literally and make each Doxy config file correspond to a .vcproj file, so that each project (eg .lib or .dll) gets its own Doxy output.
I use a subversion post-commit hook to pull out the directories that have changed, write them to a file and then every night I automatically re-generate the doxygen html on our webserver so we always have up-to-date docco.
Every project I want documented has a little project.doxy file that contains the per-project settings and an include to the main doxygen settings - eg:
PROJECT_NAME = "AlertServer"
PROJECT_NUMBER = 8.1.2
INPUT = "C:/Dev/src/8.1.2/Common/AlertServer"
HTML_OUTPUT = "AlertServer"
#INCLUDE = "c:\dev\CommonConfig.doxy"
For Windows SVN server, use the hook:
#echo off
for /F "eol=¬ delims=¬" %%A in ('svnlook dirs-changed %1 -r %2') do echo %%A >> c:\svn_exports\export.txt
and then run this nightly:
#echo off
rem ---------------
rem remove duplicates.
type nul> %TEMP%.\TEMP.txt
for /F "eol=¬ delims=¬" %%a in (c:\svn_exports\export.txt) do (
findstr /L /C:"%%a" < %TEMP%.\TEMP.txt > nul
if errorlevel=1 echo %%a>> %TEMP%.\TEMP.txt
)
copy /y %TEMP%.\TEMP.txt export_uniq.cmd >nul
if exist %TEMP%.\TEMP.txt del %TEMP%.\TEMP.txt
rem ---------------
rem fetch all the recently changed directories into the svn_exports directory
for /F "eol=¬ delims=¬" %%A in (c:\svn_exports\export_uniq.cmd) do (
svn export "file:///d:/repos/MyRepo/%%A" "c:/svn_exports/%%A" --force
)
rem ---------------
rem search through all dirs for any config files, if found run doxygen
for /R c:\svn_exports %%i in (*.doxy) do c:\tools\doxygen\bin\doxygen.exe "%i"
rem ---------------
rem now remove the directories to be generated.
del /F c:\svn_exports
this removes duplicate entries, finds all projects that have a .doxy project file, and runs doxygen on them. Voila: fully documented, always up-to-date code on a webserver.
For complex projects it may be useful to have a separate file for module management, which controls the groups and subgroups. The whole hierarchy can be in one place and then each file can simply stuff to the child groups. e.g.:
/**
* #defgroup example Top Level Example Group
* #brief The Example module.
*
* #{
*/
/**
* #defgroup example_child1 First Child of Example
* #brief 1st of 2 example children.
*/
/**
* #defgroup example_child2 Second Child of Example
* #brief 2nd of 2 example children.
*/
// #}
Simply including the definition of a group within the { } of another group makes it a child of that group. Then in the code and header files functions can just be tagged as part of whatever group they are in and it all just works in the finished documentation. It makes refactoring the documentation to match the refactor code much easier.
Uses lots and lots of links. This can be done using see also links (\see or #see if you prefer), and making sure that you use any references to other class names in documentation by their correct class name. For example if you refer to class FUZZYObject as an "object", then write immediately after it the name of the class (e.g. "frazzle the objects (FUZZYObject)").
Automatically build and publish your documentation. As part of automatically building the documentation, pay attention to the warnings, its very easy to write badly structure doxygen comments.
Use \example as much as you can. It auto-links API elements to example code.
Don't bother with #author or #date (#date was mentioned in another post). These are both handled by a revision control system.
Always include a description with your classes. Try to say how a class is used, or why it is used, not just what it is (which usually just reflects the name anyway).
Group your member functions and fields if it makes sense to do so with \defgroup. This is very helpful, even if you don't say much.
If you are worried that some team members will avoid documenting or you just want a working minimal sets of documentation, you can enable these in your doxygen configuration.
WARNINGS = YES
WARN_IF_UNDOCUMENTED = YES
WARN_IF_DOC_ERROR = YES
As part of your doxygen build process save the warnings to a file and try to get and keep the warning count as low as possible (0 if that is reasonable). If you do this, every public and protected class member will need at least an #brief, #param for each function argument and an #return. This is good enough to describe most APIs and not too much to encumber other living codebases.
You should, of course, encourage people to document as much as they feel is required on a case by case basis, as long as they meet the minimum project standards. Don't set the minimum too high though, then you may not get useful documentation in the end.
For example, in our project, everything another coder is likely to touch should be documented. Enabling the warnings let see how close that goal we are. We also try to use #internal to describe what/why we do what we do with some of our private members.
If you find that the configuration directive INLINE_SOURCES puts too much code in the documentation, you can manually quote specific portions of the code using the \snippet command.
/**
* Requirment XYZ is implemented by the following code.
*
* \snippet file.c CODE_LABEL
*/
int D()
{
//[CODE_LABEL]
if( A )
{
B= C();
}
//[CODE_LABEL]
}
note: snippet gets its files from the EXAMPLE_PATH, not where the source path is. You will have to put the same list of files and paths from INPUT directive on the EXAMPLE_PATH directive.
For larger projects taking 5+min to generate, I found it useful to quicly be able to generate doxygen for a single file and view it in a web browser.
While references to anything outside the file won't resolve, it can still useful to see the basic formatting is ok.
This script takes a single file and the projects doxy config and runs doxygen, I've set this up to run from my IDE.
#!/usr/bin/env python3
"""
This script takes 2-3 args: [--browse] <Doxyfile> <sourcefile>
--browse will open the resulting docs in a web browser.
"""
import sys
import os
import subprocess
import tempfile
doxyfile, sourcefile = sys.argv[-2:]
tempfile = tempfile.NamedTemporaryFile(mode='w+b')
doxyfile_tmp = tempfile.name
tempfile.write(open(doxyfile, "r+b").read())
tempfile.write(b'\n\n')
tempfile.write(b'INPUT=' + os.fsencode(sourcefile) + b'\n')
tempfile.flush()
subprocess.call(("doxygen", doxyfile_tmp))
del tempfile
# Maybe handy, but also annoying as default.
if "--browse" in sys.argv:
import webbrowser
webbrowser.open("html/files.html")
Related
My PhpStorm 2017.2 project requires that each new file be created from a specific. In "Settings >> Editor >> File and Code Templates >> PHP File", I have the following template:
<?php
/**
* #author John Doe
* #copyright ${YEAR} Acme
* #created ${DATE}
* #modified ${DATE}
*/
This works well. PhpStorm fills in the year and date dynamically. However, when I later come back and make changes to the file, I always need to remember to change the #modified line manually. Is there a way to automate this so that onSave or onCommit (for version controlled file), the line is updated with the current value of ${DATE}?
Not possible ATM.
https://youtrack.jetbrains.com/issue/IDEABKL-7178 -- watch this ticket (star/vote/comment) to get notified on any progress. Right now there are no plans to implement something like that in nearest future.
On another hand (as mentioned in the comment in aforementioned ticket) -- see if standard "Copyright" plugin will be of any help (never used it myself so no idea of what exactly it can do).
One possible solution involves writing your own script/program (PHP or whatever other language you can use) that will parse your file (regex matching should do fine here -- no real need into going and parsing file into tokens) and update such info:
look at each line until the matching line will be found (some guard logic can be added to limit the number of lines to be parsed: if no matching line is found in first xx (e.g. 20) lines then assume that this file has no such comment/line);
update date/time part based on file modification timestamp.
Once you have such script -- just use File Watcher functionality so it gets called on each file modification.
Possible downside: File Watcher gets triggered when file modification is detected ... which may include changes made outside (e.g. another editor/download from remote host/another VCS branch/etc)). This may lead to unnecessary/unwanted updates.
If File Watcher functionality is not suitable for whatever reason -- look into grunt -watch or alike where you may easily disable watching (so your script will only be called when your watcher (build runner) is watching).
I am using Visual Studio 2013 (C++) with the Atomineer Utils add-in.
Coming from a Java background, I was interested in the Doxygen style of documentation, so I configured Atomineer to use the Doxygen (Javadoc) style, which looks like this basically:
/**
* #brief adds two numbers together
*/
void add(int x, int y);
However, let's say I want to start a multi-line comment. Coming from IntelliJ IDEA, I assumed this would work:
/**
enter
/**
*
or better yet:
/**
enter
/**
*
*/
In reality, this produces the strangest results:
/**
# autocompletes to
/**/
enter
/**
/* /
Hopefully you can understand how unhelpful that sort of autocomplete behavior is.
On top of that, if you manage to get a complete Doxygen comment on, extending that comment only works if (from my observations):
You aren't selecting the beginning of the comment (/**)
You are selecting after the asterisk before hitting enter, and not the space that automatically generates after it: (| represents the cursor)
/**
*|
*/
then hitting enter would work, but not
/**
* |
*/
OR you type something on that line and hit enter
Now on to how I would prefer to solve the problem: to somehow fix the multi-line comment generation and automatic extension to be similar to what I expect.
However, if you guys are certain that that kind of solution does not exist, then I am aware that Atomineer generates documentation automatically if I type /// (but why not /**!?) and I can use that instead as a sort of work-around.
What I have tried so far:
Disabled Complete Multiline Comments under Options -> Text Editor -> C/C++ -> Advanced (this disables it AND Atomineer's documentation generator)
Disabled Generate XML documentation comments for /// under Options -> Text Editor -> C# -> Advanced (We're talking C++ here so obviously this didn't do anything)
(Apologies for the late answer, I didn't spot this question earlier)
The simple work-around would have been to type /// or ctrl+shift+D to generate the comment. However, Atomineer has since been updated, and also now allows you to type /** to generate a comment.
I'm trying to get doxygen 1.8.7 to include detailed descriptions in the HTML output. For example, given the following file:
/** \file iniparse.h */
namespace ini {
/** \brief A brief description.
*
* A longer description.
*/
inline void parse() {}
}
My HTML for iniparse.h contains an entry for ini::parse, with text "A brief description. More..." The "More..." part is a broken link to a non-existent anchor in the same page. And the text "A longer description" appears nowhere in the generated HTML.
If I get rid of the namespace and just define a function parse (i.e., ::parse) outside of any namespace, things work fine. Can someone tell me how to get the same behavior inside a namespace? Thanks.
Turns out this problem is caused by a combination of three things. First, a plain old bug in doxygen:
https://bugzilla.gnome.org/show_bug.cgi?id=745481
Second, even with the bug fix, you need to generate the namespaces page or you still get broken links. Hence, you need to have SHOW_NAMESPACES = YES in your Doxyfile.
Third, unless you have EXTRACT_ALL = YES, you have to make sure the namespace itself is documented by attaching a Doxygen comment to it. So you need:
//! The ini namespace
namespace ini {
...
}
On one hand maybe it makes sense to require namespaces to be documented if you want documentation for their contents. However, it's weird that doxygen shows the first part of the documentation even without the namespace documentation. So I would argue this is still kind of a bug, but at least I know how to work around it now.
In Doxygen you use reference links: define them separately and then refer to them from within the text.
/**
* This is a documentation. Here I link [std::string] to an external web page.
*
* The next line is the link definition:
*
* [std::string]: http://en.cppreference.com/w/cpp/string/basic_string "std::string documentation"
*/
However it seems that the link definition is seen only within the documentation block. It is not seen even on other documentation blocks on the same page.
I want to define some links once, and then use them everywhere (on different pages).
Is that possible?
Edit (follow-up question)
In order to achieve your aim I think your best bet is to make use of the ALIAS facility.
I have managed to set it up with alias like this:
ALIASES += std_string="std::string "
ALIASES += std_vector="std::vector "
And using it:
#std_string
#std_vector
Basically I have one alias for each link.
Can it be achieved with one alias with parameters? The use would be:
#std_ref std::string
#std_ref std::vector
The problem is that some sort of map is needed between the name (the parameter) and the link:
std::string -> http://en.cppreference.com/w/cpp/string/basic_string
std::vector -> http://en.cppreference.com/w/cpp/container/vector
I know it can be done if one parameter would be the different part of the link, like :
#std_ref std::string string/basic_string
#std_ref std::vector container/vector
But this is ugly, error prone and would require to check each time what the link should be.
It's worth noting that what you are currently using is the notation that comes only with Doxygen's support for Markdown - it's not the doxygen method for external links. The original Doxygen method is to insert an HTML link inline...
link text
... but that makes no difference to your original problem.
In order to achieve your aim I think your best bet is to make use of the ALIAS facility. The relevant manual page is here. Using them, you should be able to define an alias like std-string and have it insert the HTML link everywhere you use the alias.
ALIASES are set up in the doxyfile config file (in this section of the manual)
You could set up aliases manually for every C++ keyword, that you want to link to, but the better way to do this is to use the doxygen TAGFILES feature.
A tag file is basically a compact representation of the entities found in the external sources. Doxygen can both generate and read tag files.
To generate a tag file for your project, simply put the name of the tag file after the GENERATE_TAGFILE option in the configuration file.
To combine the output of one or more external projects with your own project you should specify the name of the tag files after the TAGFILES option in the configuration file.
Doxygen has a whole page dedicated to explaining how to link to external documentation
And cppreference.com has already setup a tag file for you with some basic instructions.
For the impatient:
Download File:cppreference-doxygen-web.tag.xml for linking directly to cppreference.com website.
Add this line to your Doxyfile:
TAGFILES += "location/of/cppreference-doxygen-web.tag.xml=http://en.cppreference.com/w/"
In emacs when you do doc comments it correctly highlights docs that start with /**. Example:
/**
* #brief: Test
*/
would be correctly fontified with font-lock-string-face and font-lock-doc-face.
Some people do doc comments with /// instead and Emacs does not fontify this using font-lock-doc-face and font-lock-string-face. Is there a way to get emacs to fontify those types of doc comments as well? I am trying to accomplish this for C/C++ but a flexible solution would be nice.
EDIT:
After looking through the emacs source code a bit I see that this is handled in cc-fonts.el in the lisp/progmodes folder. It looks like c-font-lock-doc-comments can be called with different prefix arguments and modifying this might fix it. When I get more time I will try and see what needs to be changed.
(defconst custom-font-lock-keywords
`((,(lambda (limit)
(c-font-lock-doc-comments "///"
limit gtkdoc-font-lock-doc-comments)))))
(setq-default c-doc-comment-style (quote (gtkdoc javadoc autodoc custom)))
Not too bad just drop in a .emacs file. You can customize the keywords but I just use the default gtkdoc keywords since that works for me.
Thanks to wvxvw for the pointer to c-doc-comment-style.
After testing for a bit this does not work for multi line /// comments (each starting with /// on separate lines). Will edit if fixed.