@@ -159,6 +159,74 @@ Comments and Doc Comments
159159 * rationale: mixing ``/* */ `` and ``// `` is convenient for block commenting out code which contains comments
160160 * Descriptions of how the code works or notes within classes and functions should use ``// `` style comments
161161
162+ Doxygen Comments
163+ ~~~~~~~~~~~~~~~~
164+
165+ * While it is allowed to use ``/** */ `` style comments for documentation, we prefer ``/// `` style
166+ comments for Doxygen
167+
168+ * rationale: ``/// `` is more consistent with the rest of the C++ code
169+ * rationale: ``/// `` is easier to type and read in most editors
170+ * rationale: The Doxygen comments with ``/// `` is easier to read in the code itself, as it is
171+ more compact versus ``/** */ `` which takes up more space and requires more lines.
172+ * Note that using ``/** */ `` Doxygen comments is useful in cases when C++ header files could
173+ participate in compilation with a C compiler, for instance, in C++/C mixed packages,
174+ when exposed API is written to comply with the C standard.
175+
176+ * Need to keep consistency and adhere to the one style of Doxygen comments at least in the scope of
177+ the one file, i.e. either use ``/// `` or ``/** */ `` style comments.
178+
179+ * `Special commands <https://www.doxygen.nl/manual/commands.html >`__ like ``\brief ``, and ``@param ``
180+ are the core annotation tools of Doxygen.
181+ Doxygen recognizes words that begin with either backslashes ``(\) `` or at symbols ``(@) `` as
182+ special commands.
183+ For example, ``\param `` and ``@param `` are synonyms.
184+ It is allowed to use both of them, but please keep consistency of usage at least in the scope
185+ of one file.
186+ Note: backslashes ``(\) `` are more C++ like style, while at symbols ``(@) `` are more Java/C style.
187+
188+ * Always use ``\brief `` or ``@brief `` explicitly before the brief description, and ``\details `` or
189+ ``@details `` explicitly before the detailed description of a function or class.
190+ Start the explanation with upper case and end the line with a dot.
191+
192+ * rationale: This is the standard way to document functions and classes in Doxygen.
193+ * rationale: To avoid misinterpreting of the sections by the documentation generation tools like
194+ Doxygen and Sphinx.
195+ * rationale: It makes it easier to read the documentation and understand the structure of the
196+ comments.
197+
198+ * Use ``\param[in] `` or ``@param[in] `` to describe input parameters of a function, ``\param[out] ``
199+ or ``@param[out] `` for output parameters, and ``\param[in,out] `` or ``@param[in,out] `` for
200+ parameters that are both input and output.
201+
202+ * Use ``\return `` or ``@return `` to describe the return value of a function, ``\note `` or
203+ ``@note `` to add a note, ``\warning `` or ``@warning `` to add a warning and ``\throws `` or
204+ ``@throws `` to describe exceptions that can be thrown by a function.
205+
206+ Example:
207+
208+ This is OK:
209+
210+ .. code-block :: c++
211+
212+ /// \b rief Brief description of the function.
213+ /// \d etails Detailed description of the function.
214+ /// \p aram[in] param1 Description of the first parameter.
215+ /// \p aram[out] param2 Description of the second parameter.
216+ void my_function(int param1, int ¶m2);
217+
218+ This is **not ** OK:
219+
220+ .. code-block :: c++
221+
222+ /// Brief description of the function
223+ /**
224+ * Detailed description of the function.
225+ * \p aram param1 Description of the first parameter.
226+ * \p aram param2 Description of the second parameter.
227+ */
228+ void my_function(int param1, int ¶m2);
229+
162230Pointer Syntax Alignment
163231~~~~~~~~~~~~~~~~~~~~~~~~
164232
0 commit comments