Doxygen/de

Doxygen ist ein beliebtes Werkzeug zur Generierung von Dokumentation aus kommentierten C++ Quellen; es unterstützt auch andere gängige Programmiersprachen wie C#, PHP, Java und Python. Besuche die Doxygen Website, um mehr über das System zu erfahren, und konsultiere das Doxygen Handbuch für die vollständigen Informationen.

Dieses Dokument gibt eine kurze Einführung in Doxygen, insbesondere wie es in FreeCAD zur Dokumentation seiner Quellen verwendet wird. Auf der Seite Quelldokumentation findest Du Anweisungen zum Erstellen der FreeCAD Dokumentation, die ebenfalls online auf der FreeCAD API Website bereitgestellt wird.



Doxygen mit C++ Kode
Der Abschnitt Getting started (Step 3) im Doxygen Handbuch erwähnt die grundlegenden Möglichkeiten der Dokumentation der Quellen.

Für Mitglieder, Klassen und Namensräume gibt es grundsätzlich zwei Möglichkeiten:
 * 1) Platziere einen speziellen "Dokumentationsblock" (einen kommentierten Absatz) vor der Deklaration oder Definition der Funktion, des Elements, der Klasse oder des Namensraums. Bei Datei-, Klassen- und Namensraumelementen (Variablen) ist es auch erlaubt, die Dokumentation direkt nach dem Element zu platzieren. Siehe Abschnitt Spezielle Kommentarblöcke im Handbuch, um mehr über diese Blöcke zu erfahren.
 * 2) Platziere einen speziellen Dokumentationsblock an einer anderen Stelle (eine andere Datei oder einen anderen Ort in der gleichen Datei) und füge einen "Strukturbefehl" in den Dokumentationsblock ein. Ein Strukturbefehl verknüpft einen Dokumentationsblock mit einer bestimmten zu dokumentierenden Einheit (Funktion, Element, Variable, Klasse, Namensraum oder Datei). Siehe Abschnitt Dokumentation an anderer Stelle im Handbuch, um mehr über Strukturbefehle zu erfahren.

Hinweis:
 * Der Vorteil der ersten Option ist, dass du den Namen der Einheit (Funktion, Element, Variable, Klasse oder Namensraum) nicht wiederholen musst, da Doxygen den Code analysiert und die relevanten Informationen extrahiert.
 * Dateien können nur mit der zweiten Option dokumentiert werden, da es keine Möglichkeit gibt, einen Dokumentationsblock vor eine Datei zu stellen. Natürlich benötigen Dateimitglieder (Funktionen, Variablen, Typedefinitionen, Definitionen) keinen expliziten Strukturbefehl; einfach einen Dokumentationsblock vor oder nach ihnen zu setzen, wird gut funktionieren.

Erster Stil: Dokumentationsblock vor dem Kode
Usually you'd want to document the code in the header file, just before the class declaration or function prototype. This keeps the declaration and documentation close to each other, so it's easy to update the latter one if the first one changes.

The special documentation block starts like a C-style comment but has an additional asterisk, so ; the block ends with a matching. An alternative is using C++-style comments with an additional slash, so.

Second style: documentation block elsewhere
Alternatively, the documentation can be placed in another file (or in the same file at the top or bottom, or wherever), away from the class declaration or function prototype. In this case, you will have duplicated information, once in the actual source file, and once in the documentation file.

First file, :

Second file, :

In this case the structural command is used to indicate which source file is being documented; a structural command  indicates that the following code is a function, and the command  is used to give a small description of this function.

This way of documenting a source file is useful if you just want to add documentation to your project without adding real code. When you place a comment block in a file with one of the following extensions, , or then Doxygen will parse the comments and build the appropriate documentation, but it will hide this auxiliary file from the file list.

The FreeCAD project adds several files ending in in many directories in order to provide a description, or examples, of the code there. It is important that such files are correctly categorized in a group or namespace, for which Doxygen provides some auxiliary commands like, , and.

Example ; this file in FreeCAD's source tree gives a short explanation of the namespace.

Another example is the file. Before the implementation details of the methods, there is a documentation block that explains some details of the command framework of FreeCAD. It has various commands to structure the documentation. It even includes example code enclosed in a pair of and  keywords; when the file is processed by Doxygen this code example will be specially formatted to stand out. The keyword is used in several places to create links to named sections, subsections, pages or anchors elsewhere in the documentation. Similarly, the or  commands print "See also" and provide a link to other classes, functions, methods, variables, files or URLs. Example

Beispiel aus dem VTK-Projekt
This is an example from VTK, a 3D visualization library used to present scientific data, like finite element results, and point cloud information.

A class to store a collection of coordinates is defined in a C++ header file. The top part of the file is commented, and a few keywords are used, like, , and to indicate important parts. Inside the class, before the class method prototypes, a block of commented text explains what the function does, and its arguments.
 * Source code of vtkArrayCoordinates.h.
 * Doxygen produced documentation for the vtkArrayCoordinates class.

Erstellung der Dokumentation


To generate the source code documentation there are two basic steps:
 * 1) Create a configuration file to control how Doxygen will process the source files.
 * 2) Run  on that configuration.

The process is described in the following.


 * Make sure you have the programs and  in your system. It is also recommended to have the  program from Graphviz, in order to generate diagrams with the relationships between classes and namespaces. On Linux systems these programs can be installed from your package manager.


 * Make sure you are in the same folder as your source files, or in the toplevel directory of your source tree, if you have many source files in different sub-directories.


 * Run to create a configuration file named . If you omit this name, it will default to  without an extension.
 * This is a big, plain text file that includes many variables with their values. In the Doxygen manual these variables are called "tags". The configuration file and all tags are described extensively in the Configuration section of the manual. You can open the file with any text editor, and edit the value of each tag as necessary. In the same file you can read comments explaining each of the tags, and their default values.


 * Instead of using a text editor, you may launch to edit many tags at the same time. With this interface you may define many properties such as project information, type of output (HTML and LaTeX), use of Graphviz to create diagrams, warning messages to display, file patterns (extensions) to document or to exclude, input filters, optional headers and footers for the HTML generated pages, options for LaTeX, RTF, XML, or Docbook outputs, and many other options.


 * Another option is to create the configuration file from scratch, and add only the tags that you want with a text editor.
 * After the configuration is saved, you can run Doxygen on this configuration file.


 * The generated documentation will be created inside a folder named . It will consist of many HTML pages, PNG images for graphics, cascading style sheets, Javascript files , and potentially many sub-directories with more files depending on the size of your code. The point of entry into the documentation is , which you can open with a web browser.

If you are writing new classes, functions or an entire new workbench, it is recommended that you run periodically to see that the documentation blocks, Markdown, and special commands are being read correctly, and that all public functions are fully documented. Please also read the documentation tips located in the source code.

When generating the complete FreeCAD documentation, you don't run directly. Instead, the project uses to configure the build environment, and then  triggers compilation of the FreeCAD sources and of the Doxygen documentation; this is explained in the source documentation page.

Doxygen Auszeichnung
Alle Doxygen Dokumentation der Befehle beginnen mit einem Backslash oder einem at Symbol, je nach Wunsch. Normalerweise wird der Backslash verwendet, aber gelegentlich wird der  verwendet, um die Lesbarkeit zu verbessern.

Die Befehle können ein oder mehrere Argumente haben. Im Doxygen Handbuch werden die Argumente wie folgt beschrieben.
 * Wenn Klammern verwendet werden, ist das Argument ein einzelnes Wort.
 * Wenn Klammern verwendet werden, erstreckt sich das Argument bis zum Ende der Zeile, in der der Befehl gefunden wurde.
 * Wenn  Klammern verwendet werden, verlängert sich das Argument bis zum nächsten Absatz. Absätze werden durch eine Leerzeile oder durch ein Abschnittskennzeichen begrenzt.
 * Wenn Klammern verwendet werden, ist das Argument optional.

Some of the most common keywords used in the FreeCAD documentation are presented here.
 * , see \defgroup, and Grouping.
 * , see \ingroup, and Grouping.
 * , see \addtogroup, and Grouping.
 * , see \author; indicates the author of this piece of code.
 * , see \brief; briefly describes the function.
 * , see \file; documents a source or header file.
 * , see \page; puts the information in a separate page, not directly related to one specific class, file or member.
 * , see \package; indicates documentation for a Java package (but also used with Python).
 * , see \fn; documents a function.
 * , see \var; documents a variable; it is equivalent to, , and.
 * , see \section; starts a section.
 * , see \subsection; starts a subsection.
 * , see \namespace; indicates information for a namespace.
 * , and, see \cond; defines a block to conditionally document or omit.
 * , see \a; displays the argument in italics for emphasis.
 * , see \param; indicates the parameter of a function.
 * , see \return; specifies the return value.
 * , see \sa; prints "See also".
 * , see \note; adds a paragraph to be used as a note.

Unterstützungsabstriche
Seit Doxygen 1.8 wird die Auszeichnungssyntax in Dokumentationsblöcken erkannt. Markdown ist eine minimalistische Formatierungssprache, die von einfachen Text Emails inspiriert ist, die, ähnlich wie die Wiki Syntax, einfach und lesbar sein soll, ohne komplizierten Code wie den in HTML, LaTeX oder Doxygens eigenen Befehlen zu benötigen. Markdown hat bei freier Software an Popularität gewonnen, insbesondere in Online Plattformen wie Github, da es die Erstellung von Dokumentation ohne komplizierten Code ermöglicht. Weitere Informationen finden sich im Abschnitt Markdown Support im Doxygen Handbuch. Besuche die Markdown Webseite, um mehr über den Ursprung und die Philosophie von Markdown zu erfahren.

Doxygen unterstützt einen Standardsatz von Auszeichnungsanweisungen sowie einige Erweiterungen wie z.B. Github Markdown. Im Folgenden werden einige Beispiele für die Formatierung von Markdown vorgestellt.

Das Folgende ist Standard Markdown. {{Code|code= Hier ist der Text für einen Absatz.

Wir machen mit mehr Text in einem anderen Absatz weiter.

Dies ist eine Level 1 Kopfzeile

=
===========

Dies ist eine Level 2 Kopfzeile.

=
===========


 * 1) This is a level 1 header


 * 1) This is level 3 header #######

> This is a block quote > spanning multiple lines

- Item 1

More text for this item.

- Item 2 * nested list item. * another nested item. - Item 3

1. First item. 2. Second item.


 * single asterisks: emphasis*

_single underscores_

**double asterisks: strong emphasis**

__double underscores__

This a normal paragraph

This is a code block

We continue with a normal paragraph again.

Use the `printf` function. Inline `code`.

[The link text](http://example.net/)

![Caption text](/path/to/img.jpg)

 }}

The following are Markdown extensions. [TOC]

First Header | Second Header - | - Content Cell | Content Cell Content Cell | Content Cell

~ {.py} class Dummy: pass ~
 * 1) A class

~ {.c} int func(int a, int b) { return a*b; } ~

``` int func(int a, int b) { return a*b; } ```

Zerteilen von Dokumentationsblöcken
Der Text in einem speziellen Dokumentationsblock wird analysiert, bevor er in die HTML- und LaTeX Ausgabedateien geschrieben wird. Beim Zertilen (engl.: Parsen) finden die folgenden Schritte statt:
 * Die Markdown Formatierung wird durch entsprechendes HTML oder spezielle Befehle ersetzt.
 * Die speziellen Befehle innerhalb der Dokumentation werden ausgeführt. Siehe Abschnitt Spezielle Befehle im Handbuch für eine Erklärung der einzelnen Befehle.
 * Wenn eine Zeile mit einem Leerzeichen beginnt, gefolgt von einem oder mehreren Sternchen und dann optional mehr Leerzeichen, dann werden alle Leerzeichen und Sternchen entfernt.
 * Alle resultierenden Leerzeilen werden als Absatztrennzeichen behandelt.
 * Links werden automatisch für Wörter erstellt, die den dokumentierten Klassen oder Funktionen entsprechen. Wenn dem Wort ein Prozentsymbol vorangestellt ist, wird dieses Symbol entfernt und es wird keine Verknüpfung für das Wort erstellt.
 * Links werden erstellt, wenn bestimmte Muster im Text gefunden werden. Weitere Informationen finden Sie im Abschnitt Automatische Linkerzeugung im Handbuch.
 * HTML-Tags, die sich in der Dokumentation befinden, werden interpretiert und für die LaTeX Ausgabe in LaTeX Äquivalente umgewandelt. Siehe den Abschnitt HTML-Befehle im Handbuch für eine Erklärung der einzelnen unterstützten HTML-Tags.

Doxygen mit Python Code
Doxygen funktioniert am besten für statisch typisierte Sprachen wie C++. Es kann aber auch eine Dokumentation für Python-Dateien erstellen.

Es gibt zwei Möglichkeiten, Dokumentationsblöcke für Python zu schreiben:
 * 1) Der pythonische Weg, mit "docstrings", d.h. ein Textblock, der von   unmittelbar nach der Klassen- oder Funktionsdefinition umgeben ist.
 * 2) Der Doxygen Weg, bei dem Kommentare vor die Klassen- oder Funktionsdefinition gestellt werden; in diesem Fall werden doppelte Hash-Zeichen  verwendet, um den Dokumentationsblock zu starten, und dann kann ein einzelnes Hash Zeichen in nachfolgenden Zeilen verwendet werden.

Hinweis:
 * Die erste Option wird bevorzugt, um PEP8, PEP257 und die meisten Stilrichtlinien für das Schreiben von Python zu erfüllen (siehe 1, 2). Es wird empfohlen, diesen Stil zu verwenden, wenn du beabsichtigst, dokumentierte Quellen mit Sphinx zu erzeugen, einem sehr gebräuchlichen Werkzeug zur Dokumentation von Python Code. Wenn Du diesen Stil verwendest, kann Doxygen die Kommentare wörtlich extrahieren, aber spezielle Doxygen Befehle, die mit oder  beginnen, funktionieren nicht.
 * Die zweite Option ist nicht der traditionelle Python Stil, aber sie erlaubt es Dir, die speziellen Befehle von Doxygen wie und  zu verwenden.

Erster Stil: Pythonische Dokumentation
Im folgenden Beispiel steht am Anfang eine docstring, um den allgemeinen Inhalt dieses Moduls (Datei) zu erklären. Dann erscheinen docstrings innerhalb der Funktions-, Klassen- und Klassenmethodendefinitionen. Auf diese Weise extrahiert Doxygen die Kommentare und präsentiert sie so, wie sie sind, ohne Änderungen.

Zweiter Stil: Dokumentationsblock vor dem Code
In the following example the documentation blocks start with double hash signs. One appears at the beginning to explain the general content of this module (file). Then there are blocks before the function, class, and class method definitions, and there is one block after a class variable. In this way, Doxygen will extract the documentation, recognize the special commands, , and , and format the text accordingly.

Compiling the documentation
Compilation of documentation proceeds the same as for C++ sources. If both Python files, and, with distinct commenting style are in the same directory, both will be processed.

The documentation should show similar information to the following, and create appropriate links to the individual modules and classes.

Converting the Pythonic style to Doxygen style
In the previous example, the Python file that is commented in a Doxygen style shows more detailed information and formatting for its classes, functions, and variables. The reason is that this style allows Doxygen to extract the special commands that start with or, while the Pythonic style does not. Therefore, it would be desirable to convert the Pythonic style to Doxygen style before compiling the documentation. This is possible with an auxiliary Python program called doxypypy. This program is inspired by an older program called doxypy, which would take the Pythonic  and convert them to the Doxygen comment blocks that start with a double hash. Doxypypy goes further than this, as it analyzes the docstrings and extracts items of interest like variables and arguments, and even doctests (example code in the docstrings).

Doxypypy can be installed using, the Python package installer.

If the command is used without the  option, it will require superuser (root) privileges to install the package, but this is not needed in most cases; use root permissions only if you are certain the package won't collide with your distribution provided packages.

If the package was installed as a user, it may reside in your home directory, for example, in. If this directory is not in your system's, the program will not be found. Therefore, add the directory to the variable, either in your  file, or in your  file.

Alternatively, you can create a symbolic link to the program, placing the link in a directory that is already included in the.

Once the program is installed, and accessible from the terminal, a Python file with Pythonic docstrings can be reformatted to Doxygen style with the following instructions. The program outputs the reformatted code to standard output, so redirect this output to a new file.

The original file has a comment at the top  that indicates the module or namespace that is being described by the file. This keyword is not interpreted when using triple quotes in the comment block.

In the new file the commenting style is changed so the line becomes, which now will be interpreted by Doxygen. However, to be interpreted correctly, the argument has to be edited manually to match the new module (file) name; after doing this the line should be.

(the top is manually edited, the rest stays the same)

To compile, create the configuration, and run in the toplevel directory that contains the files.

The documentation should show similar information to the following, and create appropriate links to the individual modules.

Converting the comment style on the fly
In the previous example, the conversion of the documentation blocks was done manually with only one source file. Ideally we want this conversion to occur automatically, on the fly, with any number of Python files. To do this, the Doxygen configuration must be edited accordingly.

To start, don't use the program directly; instead, create the configuration file with, then edit the created , and modify the following tag.

What this does is that files that match the pattern, all files with a extension ending in, will go through the program. Every time Doxygen encounters such file in the source tree, the file name will be passed as the first argument to this program.

The program does not exist by default; it should be created as a shell script to run  with the appropriate options, and to take a file as its first argument.

After saving this shell script, make sure it has execute permissions, and that it is located in a directory contained in your system's.

On Windows systems, a batch file can be used in a similar way.

With this configuration done, the command can be run to generate the documentation as usual. Every Python file using Pythonic  will be reformatted on the fly to use  style comments, and then will be processed by Doxygen, which now will be able to interpret the special commands and Mardown syntax. The original source code won't be modified, and no temporary file with a different name needs to be created as in the previous section; therefore, if a instruction is found, it doesn't need to be changed manually.

Note that existing Python files which already use the style for their comment blocks won't be affected by the  filter, and will be processed by Doxygen normally.



Python code quality check
To use the automatic conversion of documentation blocks it is important that the original Python sources are correctly written, following the Pythonic guidelines in PEP8 and PEP257. Sloppily written code will cause to fail when processing the file, and thus Doxygen will be unable to format the documentation correctly.

The following commenting styles will not allow parsing of the docstrings by, so they should be avoided.

Always use triple quotes for the docstrings, and make sure they immediately follow the class or function declaration.

It is also a good idea to verify the quality of your Python code with a tool such as flake8 (Gitlab). Flake8 primarily combines three tools, Pyflakes, Pycodestyle (formerly pep8), and the McCabe complexity checker, in order to enforce proper Pythonic style.

To check all files inside a source tree use.

If the project demands it, some code checks deemed too strict can be ignored. The error codes can be consulted in the Pycodestyle documentation.

In similar way, a program that primarily checks that comments comply with PEP257 is Pydocstyle. The error codes can be consulted in the Pydocstyle documentation.

Also use it with to perform docstring checks on all source files.

Source documentation with Sphinx
Sphinx is the most popular system to document Python source code. However, since FreeCAD's core functions and workbenches are written in C++ it was deemed that Doxygen is a better documentation tool for this project.

While Sphinx can natively parse Python docstrings, it requires a bit more work to parse C++ sources. The Breathe (Github) project is an attempt at bridging the gap between Sphinx and Doxygen, in order to integrate both Python and C++ source code documentation in the same system. First, Doxygen needs to be configured to output an XML file; the XML output is then read by Breathe, and converted to suitable input for Sphinx.

See the Quick start guide in the Breathe documentation to know more about this process.

See this answer in Stackoverflow for other alternatives to documenting C++ and Python code together in the same project.