Lines Matching refs:code
84 .. code-block:: c
97 The normal comment prefix ``/**`` causes the comment to document the code member
98 *after* the comment. When documenting a code member that is *before* the
101 .. code-block:: c
113 - When commenting code, use block comments like this ``/* Description */``,
118 - Write readable code to avoid descriptive comments like: ``x++; /* Add 1 to x */``.
120 - The code should show clearly what you are doing.
124 - Short "code summaries" of a few lines are accepted: ``/* Calculate new coordinates */``
126 - In comments use back-quotes (\`...\`) when referring to a code element, such as a variable, type,
137 - Remember, when you are writing source code, you are not just teaching the computer
139 API, but also future maintainers of your source code. Comments add information
140 about what you were thinking when the code was written, and **why** you did things
141 that way---information that cannot be conveyed by the source code alone.
155 .. code-block:: c
173 * @code{.c}
184 - Always start Doxygen comment with a brief description of the code element it documents.
202 - Use back-quotes (\`...\`) around code elements (variables, type names, function names). For type
203 names and function names, Doxygen generates a hyperlink to that code member's
217 - Place example code in a code block by surrounding it with ``@code{.c}`` and ``@endcode`` commands.
227 .. code-block:: c
245 - ``@code{.c}/@endcode``
246 surrounds code that should be placed in a code block. While Doxygen knows to use C
247 color-coding of code blocks in a .C file, the downstream part of the documentation
248 generation sequence does not, so the ``{.c}`` appendage to the ``@code`` command
297 .. code-block:: c
324 You can use **astyle** to format the code. Run ``code-format.py`` from
332 ``lv_conf.h`` to 1 or 0 respectively. The code files that contain the logic for
362 .. code-block:: console
387 .. code-block:: console
398 .. code:: console