Instructions to prepare documentation
This commit is contained in:
Krzysztof
parent
3eaf1ec907
commit
c3f7d15246
|
|
@ -1,70 +1,91 @@
|
|||
Template API
|
||||
=============
|
||||
Template
|
||||
========
|
||||
|
||||
.. note::
|
||||
|
||||
*INSTRUCTIONS*
|
||||
|
||||
1. Use this file as a template to document API.
|
||||
2. Change the file name to the name of the header file that represents documented API.
|
||||
3. Include respective files with descriptions from the API folder using ``..include::``
|
||||
|
||||
* README.rst
|
||||
* example.rst
|
||||
|
||||
4. Optionally provide description right in this file.
|
||||
5. Once done, remove all instructions like this one and any superfluous headers.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
INSTRUCTIONS: Provide overview where and how this API may be used. For large number of functions, break down description into groups.
|
||||
.. note::
|
||||
|
||||
Use the folowing heading levels:
|
||||
*INSTRUCTIONS*
|
||||
|
||||
* # with overline, for parts
|
||||
* \* with overline, for chapters
|
||||
* =, for sections
|
||||
* -, for subsections
|
||||
* ^, for subsubsections
|
||||
* ", for paragraphs
|
||||
1. Provide overview where and how this API may be used.
|
||||
2. Where applicable include code snippets to illustrate functionality of particular functions.
|
||||
3. To distinguish between sections, use the following `heading levels <http://www.sphinx-doc.org/en/stable/rest.html#sections>`_:
|
||||
|
||||
* ``#`` with overline, for parts
|
||||
* ``*`` with overline, for chapters
|
||||
* ``=``, for sections
|
||||
* ``-``, for subsections
|
||||
* ``^``, for subsubsections
|
||||
* ``"``, for paragraphs
|
||||
|
||||
Application Example
|
||||
-------------------
|
||||
|
||||
INSTRUCTIONS: Provide one or more pratical examples to demonstrate functionality of this API.
|
||||
.. note::
|
||||
|
||||
*INSTRUCTIONS*
|
||||
|
||||
Reference
|
||||
---------
|
||||
1. Provide one or more practical examples to demonstrate functionality of this API.
|
||||
2. Break down the code into parts and describe functionality of each part.
|
||||
3. Provide screenshots if applicable.
|
||||
|
||||
INSTRUCTIONS: Provide list of API memebers divided into sections. Use coresponding **.. doxygen** directices, so member documentation is auto updated.
|
||||
API Reference
|
||||
-------------
|
||||
|
||||
* Data Structures **.. doxygenstruct**
|
||||
* Macros **.. doxygendefine**
|
||||
* Type Definitions **.. doxygentypedef**
|
||||
* Enumerations **.. doxygenenum**
|
||||
* Functions **.. doxygenfunction**
|
||||
* Variables **.. doxygenvariable**
|
||||
.. note::
|
||||
|
||||
Include code snippotes to ilustrate functionality of particular functions where applicable. Skip section hearder if empty.
|
||||
*INSTRUCTIONS*
|
||||
|
||||
1. Provide list of API members divided into sections.
|
||||
2. Use corresponding ``.. doxygen..`` directives, so member documentation is auto updated.
|
||||
|
||||
* Data Structures -``.. doxygenstruct::``
|
||||
* Macros - ``.. doxygendefine::``
|
||||
* Type Definitions - ``.. doxygentypedef::``
|
||||
* Enumerations - ``.. doxygenenum::``
|
||||
* Functions - ``.. doxygenfunction::``
|
||||
|
||||
See `Breathe documentation <https://breathe.readthedocs.io/en/latest/directives.html>`_ for additional information.
|
||||
|
||||
3. Once done remove superfluous headers.
|
||||
4. When changes are committed and documentation is build, check how this section rendered. :doc:`Correct annotations <../documenting-code>` in respective header files, if required.
|
||||
|
||||
Data Structures
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
.. Data Structures .. doxygenstruct
|
||||
``.. doxygenstruct:: name_of_structure``
|
||||
|
||||
Macros
|
||||
^^^^^^
|
||||
|
||||
.. Macros .. doxygendefine
|
||||
``.. doxygendefine:: name_of_macro``
|
||||
|
||||
Type Definitions
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. Type Definitions .. doxygentypedef
|
||||
``.. doxygentypedef:: name_of_type``
|
||||
|
||||
Enumerations
|
||||
^^^^^^^^^^^^
|
||||
|
||||
.. Enumerations .. doxygenenum
|
||||
``.. doxygenenum:: name_of_enumeration``
|
||||
|
||||
Functions
|
||||
^^^^^^^^^
|
||||
|
||||
.. Functions .. doxygenfunction
|
||||
|
||||
Variables
|
||||
^^^^^^^^^
|
||||
|
||||
.. Variables .. doxygenvariable
|
||||
|
||||
|
||||
``.. doxygenfunction:: name_of_function``
|
||||
|
|
|
|||
|
|
@ -1,10 +1,18 @@
|
|||
Documenting Code
|
||||
================
|
||||
|
||||
The purpose of this description is to provide quick summary on documentation style used in `espressif/esp-idf`_ repository and how to add new documentation.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
When documenting code for this repository, please follow `Doxygen style <http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html#specialblock>`_. You are doing it by inserting special commands, for instance ``@param``, into standard comments blocks like for example ``/* @param ratio this is oxygen to air ratio */``.
|
||||
When documenting code for this repository, please follow `Doxygen style <http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html#specialblock>`_. You are doing it by inserting special commands, for instance ``@param``, into standard comments blocks, for example:
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* @param ratio this is oxygen to air ratio
|
||||
*/
|
||||
|
||||
Doxygen is phrasing the code, extracting the commands together with subsequent text, and building documentation out of it.
|
||||
|
||||
|
|
@ -14,20 +22,19 @@ Typical comment block, that contains documentation of a function, looks like bel
|
|||
:align: center
|
||||
:alt: Sample inline code documentation
|
||||
|
||||
Doxygen supports couple of formatting styles. It also gives you great flexibility on level of details to include in documentation. To get the taste of available features please check data reach and very well organized `Doxygen Manual <http://www.stack.nl/~dimitri/doxygen/manual/index.html>`_.
|
||||
Doxygen supports couple of formatting styles. It also gives you great flexibility on level of details to include in documentation. To get familiar with available features, please check data reach and very well organized `Doxygen Manual <http://www.stack.nl/~dimitri/doxygen/manual/index.html>`_.
|
||||
|
||||
Why we need it?
|
||||
---------------
|
||||
|
||||
The purpose of this description is to provide quick summary on documentation style used in `espressif/esp-idf <https://github.com/espressif/esp-idf>`_ repository.
|
||||
The ultimate goal is to ensure that all the code is consistently documented, so we can use tools like `Sphinx <http://www.sphinx-doc.org/>`_ and `Breathe <https://breathe.readthedocs.io/>`_ to aid preparation and automatic updates of API documentation when the code changes.
|
||||
|
||||
The ultimate goal is to ensure that all the code is consistently documented, so we can use tools like `Sphinx <http://www.sphinx-doc.org/>`_ and `Breathe <https://breathe.readthedocs.io/>`_ to aid preparation and automatic updates of API documentation when the code changes. The above piece of code renders in Sphinx like below:
|
||||
With these tools the above piece of code renders like below:
|
||||
|
||||
.. image:: _static/doc-code-documentation-rendered.png
|
||||
:align: center
|
||||
:alt: Sample inline code after rendering
|
||||
|
||||
|
||||
Go for it!
|
||||
----------
|
||||
|
||||
|
|
@ -57,7 +64,7 @@ When writing code for this repository, please follow guidelines below.
|
|||
|
||||
6. To provide well formatted lists, break the line after command (like ``@return`` in example below).
|
||||
|
||||
::
|
||||
.. code-block:: c
|
||||
|
||||
...
|
||||
*
|
||||
|
|
@ -70,53 +77,76 @@ When writing code for this repository, please follow guidelines below.
|
|||
*
|
||||
...
|
||||
|
||||
|
||||
7. Overview of functionality of documented header file, or group of files that make a library, should be placed in separate ``README.rst`` file.
|
||||
7. Overview of functionality of documented header file, or group of files that make a library, should be placed in the same directory in a separate ``README.rst`` file. If directory contains header files for different APIs, then the file name should be ``apiname-readme.rst``.
|
||||
|
||||
Go one extra mile
|
||||
-----------------
|
||||
|
||||
There are couple of tips how you can make your documentation even better and more useful to the reader.
|
||||
There is couple of tips, how you can make your documentation even better and more useful to the reader.
|
||||
|
||||
Add code snippets to illustrate implementation. To do so, enclose the snippet using ``@code{c}`` and ``@endcode`` commands.
|
||||
1. Add code snippets to illustrate implementation. To do so, enclose snippet using ``@code{c}`` and ``@endcode`` commands.
|
||||
|
||||
::
|
||||
.. code-block:: c
|
||||
|
||||
...
|
||||
*
|
||||
* @code{c}
|
||||
* // Example of using nvs_get_i32:
|
||||
* int32_t max_buffer_size = 4096; // default value
|
||||
* esp_err_t err = nvs_get_i32(my_handle, "max_buffer_size", &max_buffer_size);
|
||||
* assert(err == ESP_OK || err == ESP_ERR_NVS_NOT_FOUND);
|
||||
* // if ESP_ERR_NVS_NOT_FOUND was returned, max_buffer_size will still
|
||||
* // have its default value.
|
||||
* @endcode
|
||||
*
|
||||
...
|
||||
...
|
||||
*
|
||||
* @code{c}
|
||||
* // Example of using nvs_get_i32:
|
||||
* int32_t max_buffer_size = 4096; // default value
|
||||
* esp_err_t err = nvs_get_i32(my_handle, "max_buffer_size", &max_buffer_size);
|
||||
* assert(err == ESP_OK || err == ESP_ERR_NVS_NOT_FOUND);
|
||||
* // if ESP_ERR_NVS_NOT_FOUND was returned, max_buffer_size will still
|
||||
* // have its default value.
|
||||
* @endcode
|
||||
*
|
||||
...
|
||||
|
||||
To highlight some information use command ``@attention`` or ``@note``. Example below also shows how to use a numbered list.
|
||||
The code snippet should be enclosed in a comment block of the function that it illustrates.
|
||||
|
||||
::
|
||||
2. To highlight some important information use command ``@attention`` or ``@note``.
|
||||
|
||||
...
|
||||
*
|
||||
* @attention
|
||||
* 1. This API only impact WIFI_MODE_STA or WIFI_MODE_APSTA mode
|
||||
* 2. If the ESP32 is connected to an AP, call esp_wifi_disconnect to disconnect.
|
||||
*
|
||||
...
|
||||
.. code-block:: c
|
||||
|
||||
...
|
||||
*
|
||||
* @attention
|
||||
* 1. This API only impact WIFI_MODE_STA or WIFI_MODE_APSTA mode
|
||||
* 2. If the ESP32 is connected to an AP, call esp_wifi_disconnect to disconnect.
|
||||
*
|
||||
...
|
||||
|
||||
Use markdown to make your documentation even more readable. With markdown you can add headers, links, tables and more.
|
||||
Above example also shows how to use a numbered list.
|
||||
|
||||
::
|
||||
3. Use markdown to make your documentation even more readable. You will add headers, links, tables and more.
|
||||
|
||||
...
|
||||
*
|
||||
* [ESP32 Technical Reference](http://espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf)
|
||||
*
|
||||
...
|
||||
.. code-block:: c
|
||||
|
||||
...
|
||||
*
|
||||
* [ESP32 Technical Reference](http://espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf)
|
||||
*
|
||||
...
|
||||
|
||||
.. note::
|
||||
|
||||
Code snippets, notes, links, etc. will not make it to the documentation, if not enclosed in a comment block associated with one of documented objects.
|
||||
|
||||
5. Prepare one or more complete code examples together with description. Place them in a separate file ``example.rst`` in the same directory as the API header files. If directory contains header files for different APIs, then the file name should be ``apiname-example.rst``.
|
||||
|
||||
Put it all together
|
||||
-------------------
|
||||
|
||||
Once all the above steps are complete, follow instruction in :doc:`api/template` and create a single file, that will merge all individual pieces of prepared documentation. Finally add a link to this file to respective ``.. toctree::`` in ``index.rst`` file located in ``/docs`` folder.
|
||||
|
||||
OK, but I am new to Sphinx!
|
||||
---------------------------
|
||||
|
||||
1. No worries. All the software you need is well documented. It is also open source and free. Start by checking `Sphinx <http://www.sphinx-doc.org/>`_ documentation. If you are not clear how to write using rst markup language, see `reStructuredText Primer <http://www.sphinx-doc.org/en/stable/rest.html>`_.
|
||||
2. Check the source files of this documentation to understand what is behind of what you see now on the screen. Sources are maintained on GitHub in `espressif/esp-idf`_ repository in `/docs <https://github.com/espressif/esp-idf/tree/master/docs>`_ folder. You can go directly to the source file of this page by scrolling up and clicking the link in the top right corner. When on GitHub, see what's really inside, open source files by clicking ``Raw`` button.
|
||||
3. You will likely want to see how documentation builds and looks like before posting it on the GitHub. There are two options to do so:
|
||||
|
||||
* Install `Sphinx <http://www.sphinx-doc.org/>`_, `Breathe <https://breathe.readthedocs.io/>`_ and `Doxygen <http://www.stack.nl/~dimitri/doxygen/>`_ to build it locally. You would need a Linux machine for that.
|
||||
* Set up an account on `Read the Docs <https://readthedocs.org/>`_ and build documentation in the cloud. Read the Docs provides document building and hosting for free and their service works really quick and great.
|
||||
|
||||
Wrap up
|
||||
-------
|
||||
|
|
@ -124,3 +154,6 @@ Wrap up
|
|||
We love good code that is doing cool things.
|
||||
We love it even better, if it is well documented, so we can quickly make it run and also do the cool things.
|
||||
|
||||
Go ahead, contribute your code and documentation!
|
||||
|
||||
.. _espressif/esp-idf: https://github.com/espressif/esp-idf/
|
||||
|
|
|
|||
Loading…
Reference in a new issue