howto-doc.rst 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187
  1. .. _howto-doc:
  2. How to write documentation
  3. ==========================
  4. .. highlight:: rst
  5. Graphene uses `Sphinx`_ to generate the documentation in HTML form. The
  6. documentation is hosted on Read The Docs at https://graphene.readthedocs.io/.
  7. Documentation is generally written as `reStructuredText`_ files which are placed
  8. in ``Documentation/`` directory. See `Sphinx' reST primer`_ for short
  9. introduction into syntax.
  10. For code written in |nbsp| C, we use `Doxygen`_ and `Breathe`_, which is
  11. a |nbsp| Sphinx' plugin for including Doxygen documentation. Documentation of
  12. C |nbsp| language API should be written as Doxygen comments (see `Doxygen
  13. manual`_) and then included in one of the ``.rst`` files (with appropriate
  14. description) using one of the `Breathe directives`_, like
  15. ``.. doxygenfunction::`` or ``.. doxygenstruct::``.
  16. :ref:`Old Wiki <old-wiki>` is imported as it was, in Markdown, but new
  17. documentation should be written in reST.
  18. The documentation should be written with ``html`` builder of Sphinx in mind. The
  19. :file:`manpages/` subdirectory also targets ``manpage`` builder. Other builders
  20. (like ``latex``) may be considered in the future, but for now their output is
  21. not published.
  22. .. note::
  23. A |nbsp| note about terminology:
  24. ``html``, ``latex`` and ``manpage``, and also others, are Sphinx "builders":
  25. http://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-b.
  26. Sphinx can output many different formats, some of them have overlapping usage
  27. (both ``html`` and ``latex`` usually output full handbook, the difference is
  28. screen vs print), some are specialised (``manpage`` processes only selected
  29. documents for man; those documents may or may not be also used by other
  30. builders).
  31. When launched through ``make`` (like ``make -C Documentation html``), this
  32. becomes "target" in Make terminology.
  33. Building documentation
  34. ----------------------
  35. To build documentation, change directory to ``Documentation`` and use ``make``,
  36. specifying the appropriate target. The output is in the ``_build`` directory:
  37. .. code-block:: sh
  38. cd Documentation
  39. make html man
  40. firefox _build/html/index.html
  41. man _build/man/pal_loader.1
  42. Preferred reST style
  43. --------------------
  44. (This is adapted from `Python's style guide`_).
  45. - Use 3-space tab in ``.rst`` files to align the indentation with reST explicit
  46. markup, which begins with two dots and a |nbsp| space.
  47. - Wrap the paragraphs at 80th character. But don't wrap verbatim text like logs
  48. and use applicable style when wrapping code examples (see ``CODESTYLE.md`` in
  49. the repository).
  50. - For headers, use Python convention for header hierarchy:
  51. 1. ``#`` with overline,
  52. 2. ``*`` with overline,
  53. 3. ``=``,
  54. 4. ``-``,
  55. 5. ``^``,
  56. 6. ``"``.
  57. Example::
  58. ###################################
  59. Very top level header (in TOC etc.)
  60. ###################################
  61. *******************
  62. Less than top level
  63. *******************
  64. Per-file header
  65. ===============
  66. Section header
  67. --------------
  68. Subsection header
  69. ^^^^^^^^^^^^^^^^^
  70. Subsubsection header
  71. """"""""""""""""""""
  72. This means most documents use only ``=`` and ``-`` adornments.
  73. .. tip::
  74. For vim users:
  75. you can enter the ``-`` underlines using the key combination
  76. ``yypVr-`` and the other adornments with similar combinations.
  77. For Emacs users:
  78. Read more at https://docutils.sourceforge.io/docs/user/emacs.html.
  79. - Use ``|nbsp|`` to insert non-breaking space. This should be added after
  80. one-letter words and where otherwise appropriate::
  81. This is a |nbsp| function.
  82. This substitution is added to all documents processed by Sphinx. For files
  83. processed also by other software (like ``README.rst``, which is both rendered
  84. by GitHub and included in ``index.rst``), use ``|_|`` after adding this
  85. substitution yourself::
  86. .. |_| unicode:: 0xa0
  87. :trim:
  88. This is a |_| README.
  89. Documentation of the code should be organized into files by logical concepts,
  90. as they fit into programmer's mind. Ideally, this should match the source files,
  91. if those files were organised correctly in the first place, but the reality may
  92. be different. In case of doubt, place them as they fit the narrative of the
  93. document, not as they are placed in the source files.
  94. Documents should be grouped by general areas and presented using
  95. ``.. toctree::`` directive in :file:`index.rst` file. This causes them to be
  96. included in TOC in the main document and also in sidebar on RTD.
  97. Preferred Doxygen style
  98. -----------------------
  99. 1. Prefer Qt-style ``/*!`` and ``\param``:
  100. .. code-block:: c
  101. /*!
  102. * \brief An example function
  103. *
  104. * This function returns a number augmented by the Answer to the Ultimate
  105. * Question of Life, the Universe, and Everything.
  106. *
  107. * \param n The number to be added
  108. * \return A number 42 greater
  109. */
  110. int foo(int n) {
  111. return n + 42;
  112. }
  113. ::
  114. There is a |nbsp| very special function :c:func:`foo`:
  115. .. doxygenfunction:: foo
  116. It's an example function, but is documented!
  117. 2. In reST, do not use ``autodoxygen`` directives, and especially do not use
  118. ``.. doxygenfile::``, because documentation should be written as prose, not
  119. a |nbsp| coredump. Write an explanation, how the things go together and place
  120. the ``.. doxygenfunction::`` directives where aproppriate.
  121. Further reading
  122. ---------------
  123. - `Four kinds of documentation`_
  124. (`HN thread <https://news.ycombinator.com/item?id=21289832>`__)
  125. - `The Hitchhiker's Guide to Documentation`_ divided by audience (role in the
  126. project), with references to good real-world examples
  127. .. _reStructuredText: https://en.wikipedia.org/wiki/ReStructuredText
  128. .. _Sphinx: https://www.sphinx-doc.org/
  129. .. _Sphinx' reST primer: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
  130. .. _Doxygen: http://www.doxygen.nl/
  131. .. _Doxygen manual: http://www.doxygen.nl/manual/docblocks.html
  132. .. _Breathe: https://breathe.readthedocs.io/en/latest/
  133. .. _Breathe directives: https://breathe.readthedocs.io/en/latest/directives.html
  134. .. _Python's style guide: https://devguide.python.org/documenting/#style-guide
  135. .. _Four kinds of documentation: https://www.divio.com/blog/documentation/
  136. .. _The Hitchhiker's Guide to Documentation: https://docs-guide.readthedocs.io/en/latest/>