Doxygen/it

Introduzione
Doxygen è uno strumento popolare per la generazione di documentazione da sorgenti C++ annotate; supporta anche altri linguaggi di programmazione popolari come C#, PHP, Java e Python. Visitare il sito web Doxygen per saperne di più sul sistema e consultare il Manuale Doxygen per informazioni complete.



Doxygen e FreeCAD
Questo documento fornisce una breve introduzione a Doxygen, in particolare a come viene utilizzato in FreeCAD per documentarne i sorgenti. Visitare la pagina documentazione del codice sorgente per istruzioni sulla creazione della documentazione di FreeCAD, anch'essa ospitata online sul sito web dell'API di FreeCAD.





Doxygen col codice C++
La sezione Getting started (Step 3) del manuale Doxygen menziona i modi di base per documentare le fonti.

Per i membri, le classi e gli spazi dei nomi ci sono fondamentalmente due opzioni:
 * 1) Posizionare uno speciale "blocco di documentazione" (un paragrafo commentato) prima della dichiarazione o della definizione della funzione, membro, classe o spazio dei nomi. Per i membri di file, delle classi e dello spazio dei nomi (variabili) è anche consentito posizionare la documentazione direttamente dopo il membro. Vedere la sezione Blocchi di commenti speciali nel manuale per saperne di più su questi blocchi.
 * 2) Posizionare un blocco di documentazione speciale da qualche altra parte (un altro file o un'altra posizione nello stesso file) e inserire un "comando strutturale" nel blocco di documentazione. Un comando strutturale collega un blocco di documentazione a una determinata entità che può essere documentata (una funzione, un membro, una variabile, una classe, uno spazio dei nomi o un file). Vedere la sezione Documentation at other places ​​nel manuale per saperne di più sui comandi strutturali.

Nota:
 * Il vantaggio della prima opzione è che non si deve ripetere il nome dell'entità (funzione, membro, variabile, classe o spazio dei nomi), poiché Doxygen analizzerà il codice ed estrarrà le informazioni rilevanti.
 * I file possono essere documentati solo utilizzando la seconda opzione, poiché non è possibile inserire un blocco di documentazione prima di un file. Naturalmente, i membri del file (funzioni, variabili, typedef, define) non necessitano di un comando strutturale esplicito; semplicemente mettendo un blocco di documentazione prima o dopo di questi tutto funzionerà correttamente.



Primo stile: blocco della documentazione prima del codice
Di solito si desidera documentare il codice nel file di intestazione, appena prima della dichiarazione di classe o del prototipo di funzione. Ciò mantiene la dichiarazione e la documentazione vicine l'una all'altra, quindi è facile aggiornare quest'ultima se la prima cambia.

Il blocco di documentazione speciale inizia come un commento in stile C ma ha un asterisco aggiuntivo, quindi ; il blocco termina con un  corrispondente. Un'alternativa è utilizzare i commenti in stile C++ con una barra aggiuntiva, quindi.



Secondo stile: blocco della documentazione altrove
In alternativa, la documentazione può essere collocata in un altro file (o nello stesso file in alto o in basso, o dovunque), lontano dalla dichiarazione di classe o dal prototipo di funzione. In questo caso, avrai informazioni duplicate, una volta nel file di origine effettivo e una volta nel file di documentazione.

Primo file, :

Secondo file, :

In questo caso viene usato il comando strutturale per indicare quale file sorgente si sta documentando; un comando strutturale  indica che il seguente codice è una funzione, e il comando  è usato per dare una breve descrizione di questa funzione.

Questo modalità di documentare un file sorgente è utile se vuoi solo aggiungere documentazione al tuo progetto senza aggiungere codice reale. Quando si inserisce un blocco di commento in un file con una delle seguenti estensioni, o , Doxygen analizzerà i commenti e creerà la documentazione appropriata, ma nasconderà questo file ausiliario dall'elenco dei file.

Il progetto FreeCAD contiene diversi file che terminano con in molte cartelle per fornire una descrizione, o esempi, del codice presente. È importante che tali file siano correttamente categorizzati in un gruppo o in uno spazio dei nomi, per il quale Doxygen fornisce alcuni comandi ausiliari come, e.

Esempio ; questo file nell'albero dei sorgenti di FreeCAD fornisce una breve spiegazione dello spazio dei nomi.

Un altro esempio è il file. Prima dei dettagli di implementazione dei metodi, c'è un blocco di documentazione che spiega alcuni dettagli del framework di comando di FreeCAD. Ha vari comandi per strutturare la documentazione. Include anche codice di esempio racchiuso in una coppia di parole chiave e ; quando il file viene elaborato da Doxygen, questo esempio di codice verrà appositamente formattato per distinguersi. La parola chiave viene utilizzata in diversi punti per creare collegamenti a sezioni, sottosezioni, pagine o ancore denominate altrove nella documentazione. Allo stesso modo, i comandi o  stampano "Vedi anche" e forniscono un collegamento ad altre classi, funzioni, metodi, variabili, file o URL. Esempio



Esempio dal progetto VTK
Questo è un esempio da, una libreria di visualizzazione 3D utilizzata per presentare dati scientifici, come risultati di elementi finiti e informazioni sulla nuvola di punti.

Una classe per archiviare una raccolta di coordinate è definita in un file di intestazione C++. La parte superiore del file è commentata e vengono utilizzate alcune parole chiave, come, e  per indicare parti importanti. All'interno della classe, prima dei prototipi del metodo della classe, un blocco di testo commentato spiega cosa fa la funzione ei suoi argomenti.
 * Codice sorgente di vtkArrayCoordinates.h.
 * Doxygen ha prodotto la documentazione per la classe vtkArrayCoordinates.



Compilazione della documentazione


Per generare la documentazione del codice sorgente ci sono due passaggi fondamentali:
 * 1) Creare un file di configurazione per controllare come Doxygen elaborerà i file sorgente.
 * 2) Eseguire  su quella configurazione.

Il processo è descritto di seguito.


 * Assicurarsi di avere i programmi e  nel proprio sistema. Si consiglia inoltre di avere il programma  da, per generare diagrammi con le relazioni tra classi e spazi dei nomi. Sui sistemi Linux questi programmi possono essere installati dal tuo gestore di pacchetti.


 * Assicurarsi di essere nella stessa cartella dei tuoi file di origine, o nella directory di livello superiore del tuo albero di origine, se si hanno molti file di origine in diverse sotto cartelle.


 * Eseguire per creare un file di configurazione chiamato . Se si omette questo nome, il valore predefinito sarà  senza estensione.
 * Questo è un grande file di testo semplice che include molte variabili con i loro valori. Nel manuale Doxygen queste variabili sono chiamate "tag". Il file di configurazione e tutti i tag sono ampiamente descritti nella sezione Configurazione del manuale. È possibile aprire il file con qualsiasi editor di testo e modificare il valore di ogni tag secondo necessità. Nello stesso file puoi leggere i commenti che spiegano ciascuno dei tag e i loro valori predefiniti.


 * Invece di utilizzare un editor di testo, si può avviare per modificare più tag contemporaneamente. Con questa interfaccia è possibile definire molte proprietà come informazioni sul progetto, tipo di output (HTML e LaTeX), utilizzo di Graphviz per creare diagrammi, messaggi di avviso da visualizzare, modelli di file (estensioni) da documentare o escludere, filtri di input, intestazioni opzionali e piè di pagina per le pagine generate in HTML, opzioni per output LaTeX, RTF, XML o Docbook e molte altre opzioni.


 * Un'altra opzione è creare il file di configurazione da zero e aggiungere solo i tag desiderati con un editor di testo.
 * Dopo aver salvato la configurazione, si può eseguire Doxygen su questo file di configurazione.


 * La documentazione generata verrà creata all'interno di una cartella denominata . Consisterà in molte pagine HTML, immagini PNG per la grafica, fogli di stile a cascata, file Javascript e potenzialmente molte sotto cartelle con più file a seconda sulla dimensione del codice. Il punto di accesso alla documentazione è , che si può aprire con un browser web.

Se si stanno scrivendo nuove classi, funzioni o un intero nuovo workbench, si consiglia di eseguire periodicamente per verificare che la documentazione blocchi Markdown e special commands vengano letti correttamente e che tutte le funzioni pubbliche siano completamente documentate. Si prega di leggere anche i suggerimenti per la documentazione che si trovano nel codice sorgente.

Quando si genera la documentazione completa di FreeCAD, non si esegue direttamente. Invece, il progetto utilizza per configurare l'ambiente di compilazione, quindi  avvia la compilazione dei sorgenti di FreeCAD e della documentazione di Doxygen; questo è spiegato nella pagina documentazione sorgente.



markup di Doxygen
All Doxygen documentation commands start with a backslash or an at-symbol, at your preference. Normally the backslash is used, but occasionally the  is used to improve readability.

The commands can have one or more arguments. In the Doxygen manual the arguments are described as follows.
 * If braces are used the argument is a single word.
 * If braces are used the argument extends until the end of the line on which the command was found.
 * If  braces are used the argument extends until the next paragraph. Paragraphs are delimited by a blank line or by a section indicator.
 * If brackets are used the argument is 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.

Markdown support
Since Doxygen 1.8, Markdown syntax is recognized in documentation blocks. Markdown is a minimalistic formatting language inspired by plain text email which, similar to wiki syntax, intends to be simple and readable without requiring complicated code like that found in HTML, LaTeX or Doxygen's own commands. Markdown has gained popularity with free software, especially in online platforms like Github, as it allows creating documentation without using complicated code. See the Markdown support section in the Doxygen manual to learn more. Visit the Markdown website to learn more about the origin and philosophy of Markdown.

Doxygen supports a standard set of Markdown instructions, as well as some extensions such as Github Markdown. Some examples of Markdown formatting are presented next.

The following is standard Markdown. {{Code|code= Here is text for one paragraph.

We continue with more text in another paragraph.

This is a level 1 header

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

This is a level 2 header


 * 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; } ```

Parsing of documentation blocks
The text inside a special documentation block is parsed before it is written to the HTML and LaTeX output files. During parsing the following steps take place:
 * Markdown formatting is replaced by corresponding HTML or special commands.
 * The special commands inside the documentation are executed. See the section Special Commands in the manual for an explanation of each command.
 * If a line starts with some whitespace followed by one or more asterisks and then optionally more whitespace, then all whitespace and asterisks are removed.
 * All resulting blank lines are treated as paragraph separators.
 * Links are automatically created for words corresponding to documented classes or functions. If the word is preceded by a percentage symbol, then this symbol is removed, and no link is created for the word.
 * Links are created when certain patterns are found in the text. See the section Automatic link generation in the manual for more information.
 * HTML tags that are in the documentation are interpreted and converted to LaTeX equivalents for the LaTeX output. See the section HTML Commands in the manual for an explanation of each supported HTML tag.

Doxygen with Python code
Doxygen works best for statically typed languages like C++. However, it can also create documentation for Python files.

There are two ways to write documentation blocks for Python:
 * 1) The Pythonic way, using "docstrings", that is, a block of text surrounded by   immediately after the class or function definition.
 * 2) The Doxygen way, putting comments before the class or function definition; in this case double hash characters  are used to start the documentation block, and then a single hash character can be used in subsequent lines.

Note:
 * The first option is preferred to comply with PEP8, PEP257 and most style guidelines for writing Python (see 1, 2). It is recommended to use this style if you intend to produce documented sources using Sphinx, which is a very common tool to document Python code. If you use this style, Doxygen will be able to extract the comments verbatim, but Doxygen special commands starting with or  won't work.
 * The second option isn't the traditional Python style, but it allows you to use Doxygen's special commands like and.

First style: Pythonic documentation
In the following example one docstring is at the beginning to explain the general contents of this module (file). Then docstrings appear inside the function, class, and class method definitions. In this way, Doxygen will extract the comments and present them as is, without modification.

Second style: documentation block before the 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.

Related

 * Source documentation
 * FreeCAD API website