The source code and dockerfile for the GSW2024 AI Lab.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.

118 lines
4.1 KiB

2 months ago
  1. Documentation {#documentation}
  2. ==============================
  3. On this page, we refer to some internal documentation rules.
  4. We use doxygen to generate our documentation and code reference.
  5. The most important conventions for documentation in CArL are collected here.
  6. Note that some of the documentation may be incomplete or rendered incorrectly, especially if you use an old version of doxygen. Here is a list of known problems:
  7. - Comments in code blocks (see below) may not work correctly (e.g. with doxygen 1.8.1.2). See [here](http://doxygen.10944.n7.nabble.com/Including-doc-comments-in-code-blocks-in-markdown-td5592.html) for a workaround. This will however look ugly for newer doxygen versions, hence we do not use it.
  8. - Files with `static_assert` statements will be incomplete. A [patch](https://bugzilla.gnome.org/show_bug.cgi?id=737172) is pending and will hopefully make it into doxygen 1.8.9.
  9. - Member groups (usually used to group operators) may or may not work. There still seem to be a few cases where doxygen [messes up](https://bugzilla.gnome.org/show_bug.cgi?id=737112).
  10. - Documenting unnamed parameters is not possible. A corresponding [ticket](https://bugzilla.gnome.org/show_bug.cgi?id=152990) exists for several years.
  11. ## Modules
  12. In order to structure the reference, we use the concept of
  13. [Doxygen modules](http://www.stack.nl/~dimitri/doxygen/manual/grouping.html#modules).
  14. Such modules are best thought of as a hierarchical set of tags, called groups.
  15. We define those groups in `/doc/markdown/codedocs/groups.dox`.
  16. Please make sure to put new files and classes in the appropriate groups.
  17. ## Literature references
  18. Literature references should be provided when appropriate.
  19. We use a bibtex database located at `/doc/literature.bib` with the following conventions:
  20. - Label for one author: `LastnameYY`, for example `Ducos00` for @cite Ducos00 .
  21. - Label for multiple authors: `ABCYY` where `ABC` are the first letters of the authors last names. For example `GCL92` for @cite GCL92 .
  22. - Order the bibtex entrys by label.
  23. These references can be used with `@cite label`, for example like this:
  24. @code
  25. /**
  26. * Checks whether the polynomial is unit normal
  27. * @see @cite GCL92, page 39
  28. * @return If polynomial is normal.
  29. */
  30. bool isNormal() const;
  31. @endcode
  32. ## Code comments
  33. ### File headers
  34. @code
  35. /**
  36. * @file <filename>
  37. * @ingroup <groupid1>
  38. * @ingroup <groupid2>
  39. * @author <author1>
  40. * @author <author2>
  41. *
  42. * [ Short description ]
  43. */
  44. @endcode
  45. Descriptions may be omitted when the file contains a single class, either implementation or declaration.
  46. ### Namespaces
  47. Namespaces are documented in a separate file, found at '/doc/markdown/codedocs/namespaces.dox'
  48. ### Class headers
  49. @code
  50. /**
  51. * @ingroup <groupid>
  52. * [ Description ]
  53. * @see <reference>
  54. * @see <OtherClass>
  55. */
  56. @endcode
  57. ### Method headers
  58. @code
  59. /**
  60. * [ Usage Description ]
  61. * @param <p1> [ Short description for first parameter ]
  62. * @param <p2> [ Short description for second parameter ]
  63. * @return [ Short description of return value ]
  64. * @see <reference>
  65. * @see <otherMethod>
  66. */
  67. @endcode
  68. These method headers are written directly above the method declaration.
  69. Comments about the implementation are written above the or inside the implementation.
  70. The `see` command is used likewise as for classes.
  71. ### Method groups
  72. There are some cases when documenting each method is tedious and meaningless, for example operators.
  73. In this case, we use doxygen method groups.
  74. For member operators (for example `operator+=`), this works as follows:
  75. @code
  76. /// @name In-place addition operators
  77. /// @{
  78. /**
  79. * Add something to this polynomial and return the changed polynomial.
  80. * @param rhs Right hand side.
  81. * @return Changed polynomial.
  82. */
  83. MultivariatePolynomial& operator+=(const MultivariatePolynomial& rhs);
  84. MultivariatePolynomial& operator+=(const Term<Coeff>& rhs);
  85. MultivariatePolynomial& operator+=(const Monomial& rhs);
  86. MultivariatePolynomial& operator+=(Variable::Arg rhs);
  87. MultivariatePolynomial& operator+=(const Coeff& rhs);
  88. /// @}
  89. @endcode
  90. ## Writing out-of-source documentation
  91. Documentation not directly related to the source code is written in Markdown format, and is located in
  92. `/doc/markdown/`.