Guidelines for API documentation » History » Version 17
neels, 02/01/2019 02:09 AM
1 | 1 | neels | h1. Guidelines for API documentation |
---|---|---|---|
2 | |||
3 | 12 | neels | Find the current API doc in HTML form here: http://ftp.osmocom.org/api/latest/ |
4 | |||
5 | 13 | neels | We use doxygen for API documentation, for an overview see http://www.doxygen.nl/manual/docblocks.html. Please follow these guidelines: |
6 | 1 | neels | |
7 | 14 | neels | h2. Marker style |
8 | |||
9 | 1 | neels | Use the @/*!@ (Qt-style) doxygen markers. |
10 | 14 | neels | <pre> |
11 | /*! Item summary. |
||
12 | * Details follow. */ |
||
13 | struct item { |
||
14 | int member; /*!< Member summary. */ |
||
15 | }; |
||
16 | </pre> |
||
17 | 1 | neels | |
18 | 14 | neels | h2. Summary |
19 | |||
20 | Since we are using the AUTOBRIEF feature, omit '\brief', and always end the first sentence with a full-stop "." to mark the end of the short description. |
||
21 | |||
22 | To have a dot in a summary, use an escaped space like |
||
23 | 1 | neels | <pre>/*! Brief description (e.g.\ using only a few words). Details follow. */</pre> |
24 | |||
25 | Never rely on line breaks as semantic separation or to end a sentence, always use proper punctuation. The API doc may be rendered with different line breaks than in the source file. |
||
26 | 4 | neels | |
27 | h2. Locations |
||
28 | |||
29 | Header files usually contain merely function declarations bare of any API docs. The API doc comment should be in a @.c@ file at the definition of a function. |
||
30 | |||
31 | Structs and enums defined in a header file, though, also have their API doc comments in that @.h@ file. |
||
32 | 10 | neels | |
33 | Comments for single-line items like enum values or struct members can be placed on the same line using @/*!< Description */@. |
||
34 | 4 | neels | |
35 | h2. Grammar |
||
36 | |||
37 | Always use the imperative form, i.e. omit wording like "This function does", and avoid writing documentation that merely mirrors a function's name. For example: |
||
38 | |||
39 | <pre> |
||
40 | /*! Return a (static) buffer containing a hexdump of the msg. |
||
41 | * \param[in] msg message buffer |
||
42 | 15 | neels | * \return a pointer to a static char array |
43 | 4 | neels | */ |
44 | const char *msgb_hexdump(const struct msgb *msg) |
||
45 | { |
||
46 | ... |
||
47 | </pre> |
||
48 | |||
49 | 1 | neels | h2. Parameters |
50 | 12 | neels | |
51 | 4 | neels | All parameters of a function should be documented. Input params are documented with @\param[in]@, where out-parameters (pointers to which returned data is written) are documented with @\param[out]@. Rarely, a param is both: @\param[in,out]@. |
52 | |||
53 | <pre> |
||
54 | /*! Apply nifty algorithm. |
||
55 | * \param[in] x0 First factor. |
||
56 | * \param[in] n Amount of values to calculate. |
||
57 | * \param[out] buf Write calculated values to this buffer. |
||
58 | * |
||
59 | 1 | neels | * Optional longer function description. */ |
60 | 7 | neels | </pre> |
61 | 8 | neels | |
62 | 4 | neels | It is also possible to document parameters without a direction, using merely @\param param_name Description@, however, it is desirable to always indicate @[in]@, @[out]@ or @[inout]@. |
63 | 1 | neels | |
64 | 16 | osmith | Parameters can *not* be referenced with @\ref@, nor with @\a@. See "this post":https://lists.osmocom.org/pipermail/openbsc/2019-January/012603.html for details. |
65 | |||
66 | 1 | neels | h2. File comments |
67 | |||
68 | 17 | neels | Choose distinct names in the '\file' directive: similar names will Doxygen, even if they are in separate subdirs and even separate libraries. |
69 | An example is osmocom/code/stats.h vs osmocom/vty/stats.h. If both of these are advertised as '\file stats.h', the duplicate handle will lead to both files missing from their respective groups. |
||
70 | Solutions: |
||
71 | |||
72 | * write '\file core/stats.h' and '\file vty/stats.h' |
||
73 | * do not use identical file names in the first place |
||
74 | |||
75 | Descriptions: |
||
76 | |||
77 | 1 | neels | If a file contains a descriptive comment, this comment should be right at the start of the file, as a doxygen @\file@ section. |
78 | The first sentence must be ended by a full stop "." to mark the end of the short description. |
||
79 | The copyright notice shall not be part of such API doc file comment. |
||
80 | |||
81 | <pre> |
||
82 | /*! \file foo.c |
||
83 | * Short description. */ |
||
84 | /* |
||
85 | * (C) 2017 ... Copyright not in a doxygen comment |
||
86 | * license information |
||
87 | */ |
||
88 | </pre> |
||
89 | |||
90 | 17 | neels | A more detailed description may follow later. Typically though, we place longer descriptions in groups, see below. |
91 | 1 | neels | |
92 | <pre> |
||
93 | /*! \file foo.c |
||
94 | * Short description. |
||
95 | */ |
||
96 | /* |
||
97 | * (C) 2017 ... |
||
98 | 17 | neels | */ |
99 | |||
100 | /*! \file foo.c |
||
101 | * |
||
102 | * More information in multiple lines. |
||
103 | 1 | neels | */ |
104 | </pre> |
||
105 | 11 | neels | |
106 | 9 | neels | If a file needs no description, it is ok to omit the @\file@ tag entirely. Since we are using EXTRACT_ALL = YES, files lacking a @\file@ tag are still listed in the API docs. |
107 | 1 | neels | |
108 | h2. Groups |
||
109 | |||
110 | Doxygen allows grouping elements: a group can include code elements and also entire files. |
||
111 | |||
112 | This works by enclosing the items to be grouped between an opening and a closing marker: |
||
113 | |||
114 | * A @\defgroup@ initially defines a group, this shall exist only once. |
||
115 | * More items can be added using an @\addtogroup@ marker. |
||
116 | * Both have to be closed by "@}". |
||
117 | |||
118 | For example: |
||
119 | |||
120 | <pre> |
||
121 | /*! \defgroup groupname Short description of the group. |
||
122 | * @{ |
||
123 | */ |
||
124 | |||
125 | struct type_that_belongs_to_group { |
||
126 | ... |
||
127 | }; |
||
128 | |||
129 | void func_that_belongs_to_group() |
||
130 | { |
||
131 | ... |
||
132 | } |
||
133 | |||
134 | /*! @} */ |
||
135 | </pre> |
||
136 | |||
137 | and |
||
138 | |||
139 | <pre> |
||
140 | /*! \addtogroup groupname |
||
141 | * @{ |
||
142 | */ |
||
143 | 3 | neels | |
144 | 1 | neels | ... |
145 | |||
146 | /*! @} */ |
||
147 | </pre> |
||
148 | 5 | neels | |
149 | 1 | neels | If a *file* should be added to a group, add a (possibly second) short descriptionless @\file@ tag to the group start. To clearly mark that the purpose is to add to the group, do so within the same comment block: |
150 | |||
151 | <pre> |
||
152 | 2 | neels | /*! \file foo.c |
153 | 1 | neels | * File's description. */ |
154 | /* |
||
155 | * (C) ... |
||
156 | */ |
||
157 | |||
158 | /*! \addtogroup groupname |
||
159 | * @{ |
||
160 | * \file foo.c */ |
||
161 | |||
162 | ... |
||
163 | |||
164 | /*! @} */ |
||
165 | </pre> |
||
166 | |||
167 | The point is that we like to have a file's short description near the start of the file, to also serve us well when we're reading only the .h file. But to be included in a group, the doxygen group start must precede the @\file@ tag. Also, the doxygen group should rather not enclose @#include@ directives, to clearly exclude those from the group. Hence, the best way is to keep the file's actual description at the top of the file, and add a second descriptionless @\file@ with the group opening. |
||
168 | |||
169 | A group may contain a short as well as a longer description. We often @\defgroup@ in a @.h@ file but keep the longer description in an @\addtogroup@ in a @.c@ file. Any @\file@ tags must follow *after* such description, or the description will be associated with the file instead of the group: |
||
170 | |||
171 | @.h@ file: |
||
172 | <pre> |
||
173 | /*! \defgroup groupname Short description of the group. |
||
174 | * @{ |
||
175 | */ |
||
176 | |||
177 | ... |
||
178 | |||
179 | /*! @} */ |
||
180 | </pre> |
||
181 | |||
182 | @.c file: |
||
183 | |||
184 | <pre> |
||
185 | /*! \addtogroup groupname |
||
186 | * @{ |
||
187 | * Longer description of the group. |
||
188 | * - contains a |
||
189 | * - bullet list |
||
190 | * |
||
191 | * As well as a |
||
192 | * |
||
193 | * Code example |
||
194 | * block |
||
195 | 6 | neels | * |
196 | 1 | neels | * All of which must not be below the directive adding this file to the group... |
197 | * |
||
198 | * \file foo.c */ |
||
199 | |||
200 | [...] |
||
201 | |||
202 | /*! @} */ |
||
203 | </pre> |
||
204 | |||
205 | Often, a file's description matches or is identical with a group's description. In that case, the file's description header comment can be omitted to avoid duplicating identical descriptions. |
||
206 | |||
207 | <pre> |
||
208 | /* |
||
209 | * (C) 2017 ... |
||
210 | */ |
||
211 | |||
212 | /* \addtogroup group |
||
213 | * @{ |
||
214 | * Description... |
||
215 | * |
||
216 | * \file foo.c */ |
||
217 | |||
218 | ... |
||
219 | |||
220 | /* @} */ |
||
221 | </pre> |