Lines Matching full:the
26 - followed by the action (for functions): *set*, *get*, etc.
27 - closed with the subject: *name*, *size*, *state* etc.
38 - The following abbreviations are used and allowed:
60 - Exception: the **Kconfig** file and any make files require leading tab characters
65 - Write functions that use the single-responsibility principle.
73 - Use the smallest required scope.
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
106 * When more detail is needed, add a blank line then the detail.
116 - Include a space after the ``/*`` or ``/**<`` and before the ``*/`` for improved readability.
120 - The code should show clearly what you are doing.
131 1. clarity (the ease with which other programmers can understand your intention),
132 2. readability (the ease with which other programmers can read your comments),
133 3. brevity (the quality of using few words when speaking or writing).
137 - Remember, when you are writing source code, you are not just teaching the computer
138 what to do, but also teaching other programmers how it works, not only users of the
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.
146 Doxygen is the first program in a chain that generates the online LVGL API
147 documentation from the files in the LVGL repository. Doxygen detects files it should
152 The following is an illustration of an API function prototype with documentation
153 illustrating most of the Doxygen commands used in LVGL.
160 * The values for the `..._place` arguments come from the `lv_flex_align_t`
161 * enumeration and have the same meanings as they do for flex containers in CSS.
184 - Always start Doxygen comment with a brief description of the code element it documents.
186 - When more detail is needed, add a blank line below the brief description and add
188 for calling the function. Doxygen needs the blank line to separate "brief" from
189 "detail" portions of the description.
191 - Describe function parameters with the ``@param`` command. When a function writes
192 to the address contained by a pointer parameter, if not already obvious (e.g. when
193 the parameter name contains the word "out"), include the direction in the command
198 - Describe return values with the ``@return`` command.
204 documentation (when it exists) with or without the single back-quotes.
206 - Append empty "()" to function names. Doxygen will not generate a hyperlink to the
214 - Lists (e.g. of accepted parameter values) can be created by using the '-' character.
215 If the list needs to be numbered, numbers can also be used.
218 Doxygen doesn't need the ``{.c}`` part, but the downstream software does.
220 - Refer reader to additional information using the ``@see`` command. Doxygen adds a
221 "See also" paragraph. The text following the ``@see`` command will be indented.
224 a Doxygen comment like this is at the top of each new file. Doxygen will not parse
225 the file without the ``@file`` command being present.
239 the file itself when applicable (everything following it in the same comment).
241 documents ``name`` as a function parameter, and ``description`` is the text that
244 documents the return value until Doxygen encounters a blank line or another Doxygen command.
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
251 starts a paragraph where a note can be entered. The note ends with a blank line,
252 the end of the comment, or another Doxygen command that starts a new section.
253 If the note contains more than one paragraph, additional paragraphs can be added
255 add additional paragraphs to notes as indicated in the Doxygen documentation.
264 To support the auto-generation of bindings, the LVGL C API must
268 export them with :cpp:expr:`LV_EXPORT_CONST_INT(defined_value)` right after the ``define``.
271 - Widget constructor must follow the ``lv_<widget_name>_create(lv_obj_t * parent)`` pattern.
274 - ``struct`` APIs should follow the widgets' conventions. That is to receive a pointer to the ``str…
275 first argument, and the prefix of the ``struct`` name should be used as the prefix of the
277 - Functions and ``struct``\ s which are not part of the public API must begin with underscore in or…
279 - Do not ``malloc`` into a static or global variables. Instead declare the variable in ``lv_global_…
280 …structure in ``lv_global.h`` and mark the variable with :cpp:expr:`(LV_GLOBAL_DEFAULT()->variable)…
281 - To register and use callbacks one of the following needs to be followed.
283 …- Pass a pointer to a ``struct`` as the first argument of both the registration function and the c…
285 …- The last argument of the registration function must be ``void * user_data`` and the same ``user_…
286 needs to be passed as the last argument of the callback.
289 To learn more refer to the documentation of `MicroPython <integration/bindings/micropython>`__.
324 You can use **astyle** to format the code. Run ``code-format.py`` from
325 the ``scripts`` folder.
332 ``lv_conf.h`` to 1 or 0 respectively. The code files that contain the logic for
334 directive near the top of the file, and its matching ``#endif`` is at the end of the
335 file. If you add or modify such a subsystem in LVGL, whenever possible, the only
337 to include the enabling/disabling macro. Specifically:
339 - in the ``.c`` file: the ``#include`` that includes the header with the closest
342 - in the mated ``.h`` file: ``#include "lv_conf_internal.h"``
354 manager for pre-commit hooks. See the `installation
358 Once you have ``pre-commit`` installed you will need to `set up the git
359 hook scripts <https://pre-commit.com/#3-install-the-git-hook-scripts>`__
372 The ``format-source`` local hook (see ``.pre-commit-config.yaml``) runs
373 **astyle** on all the staged source and header files (that are not
374 excluded, see ``exclude`` key of the hook configuration) before entering
375 the commit message, if any file gets formatted by **astyle** you will
376 need to add the change to the staging area and run ``git commit`` again.
378 The ``trailing-whitespace`` hook fixes trailing whitespaces on all of
379 the files.
389 SKIP=name-of-the-hook git commit
395 It is not necessary to do a commit to test the hooks, you can test hooks
396 by adding the files into the staging area and run:
400 pre-commit run name-of-the-hook