Doxygen - Sinnvolle, übersichtliche Verwendung

Developer-Tools, Entwicklungsumgebungen und alles andere, was sich installieren lässt
Antworten
Benutzeravatar
Dirty Oerti
Beiträge: 2229
Registriert: Di Jul 08, 2008 5:05 pm
Wohnort: Thurndorf / Würzburg

Doxygen - Sinnvolle, übersichtliche Verwendung

Beitrag von Dirty Oerti » Fr Apr 23, 2010 6:19 pm

Tag zusammen :)

Ich bin gerade dabei für meinen Kernel eine Doxygen Dokumentation anzulegen, da sich ein paar Leute gefunden haben, die interessiert sind, daran mitzuarbeiten. Außerdem erleichtert das auch mir die Arbeit am Kernel, denn manche Funktionen vergisst man gerne einmal.
Der Kernel ist in C geschrieben. Ein paar Fetzen Assembler sind auch dabei.

Nun stellt sich natürlich die Frage wie man ein so (doch) großes Projekt sinnvoll und vorallem übersichtlich mit Doxygen Kommentaren ausstattet. Ich kenne mich leider recht wenig mit Doxygen aus, deshalb habe ich jetzt ein paar Fragen:

WO wird kommentiert? In den Headerdateien (die eigentlich FAST alles noch einmal enthalten) oder in den Quelldateien?
WIE wird kommentiert? Ich habe nun schon einige unterschiedliche Varianten gesehen, welche ist die Beste, wenn es eine gibt, und wenn ja, warum?

Dann noch ein zweites WO:
Wie platziere ich die Kommentare am sinnvollsten in den Dateien?
Ich hab das jetzt mal testweise für einen Header gemacht, das würde dann so aussehen:

Code: Alles auswählen

#ifndef __KERNEL__PHYSICALMEMORY__HEADER__
#define __KERNEL__PHYSICALMEMORY__HEADER__

#include "library/types.h"


/**
* \def MAKRO_SET_BIT(x)
* \brief Sets bit number x
*/
#define MAKRO_SET_BIT(x) (( 1 << ( (x) )))
/**
* \def FRAME_SIZE
* \brief The size of a frame in bytes
*/
#define FRAME_SIZE  0x1000
/**
* \def PHYSICAL_MAPSIZE_MB
* \brief The amount of memory managed by a single map in megabytes
*/
#define PHYSICAL_MAPSIZE_MB 8lu
/**
* \def PHYSICAL_MAPSIZE_BYTES
* \brief The amount of memory managed by a single map in bytes
*/
#define PHYSICAL_MAPSIZE_BYTES  MB_TO_BYTES(PHYSICAL_MAPSIZE_MB)
/**
* \def ADDRESS_TO_FRAME(Address)
* \brief The address of the given frame
*/
#define ADDRESS_TO_FRAME(Address) (Address >> 12)
/**
* \def FRAME_TO_ADDRESS(Frame)
* \brief The frame of the given address
*/
#define FRAME_TO_ADDRESS(Frame) (Frame << 12)
/**
* \def START_OF_FRAME(ADDR)
* \brief The startaddress of the actual frame
*/
#define START_OF_FRAME(ADDR) ((ADDR)&(0xFFFFF000))
/**
* \def START_OF_NEXT_FRAME(ADDR)
* \brief The startaddress of the next frame
*/
#define START_OF_NEXT_FRAME(ADDR) START_OF_FRAME((ADDR)+FRAME_SIZE)
/**
* \def PHYSICAL_OK
* \brief Magic value to show everything is ok
*/
#define PHYSICAL_OK 1
/**
* \def PHYSICAL_ERROR
* \brief Magic value to show that there is an error
*/
#define PHYSICAL_OK 0
//-------------------------------------------------------------------

extern UINT *____KERNELSTART;
extern UINT *____KERNELEND;
//----------------------------------------------------------------------------------
/**
* \var PhysicalKernelStart
* \brief Physical start address of the kernel memory
*/
extern UINT PhysicalKernelStart;
/**
* \var PhysicalKernelEnd
* \brief Physical end address of the kernel memory
*/
extern UINT PhysicalKernelEnd;
/**
* \var PhysicalManagedInfoStart
* \brief Physical start address of the physical information memory
*/
extern UINT PhysicalManagedInfoStart;
/**
* \var PhysicalManagedInfoEnd
* \brief Physical end address of the physical information memory
*/
extern UINT PhysicalManagedInfoEnd;
/**
* \var PhysicalSuperMapStart
* \brief Physical start address of the super map
*/
extern UINT PhysicalSuperMapStart;
/**
* \var PhysicalSuperMapSize
* \brief Size of the super map in 4 bytes
*/
extern UINT PhysicalSuperMapSize;
/**
* \var PhysicalMapsStart
* \brief Physical start address of the maps
*/
extern UINT PhysicalMapsStart;
/**
* \var PhysicalMapsCount
* \brief Number of the maps
*/
extern UINT PhysicalMapsCount;
/**
* \var PhysicalMapSize
* \brief Size of a single map in 4 bytes
*/
extern UINT PhysicalMapSize;


/**
* \fn void_free_frame(UINT Frame)
* \brief Internal function to mark the given frame as free
*/
extern void _free_frame(UINT Frame);
/**
* \fn void _use_frame(UINT Frame)
* \brief Internal function to mark the given frame as used
*/
extern void _use_frame(UINT Frame);
/**
* \fn void _use_frames(UINT Start, UINT Count)
* \brief Internal function to mark the given frame and Count-1 frames after as used
*/
extern void _use_frames(UINT Start, UINT Count);
/**
* \fn UINT8 _check_frame(UINT Frame)
* \brief Internal function to check whether a frame is marked as used or not
*/
extern UINT8 _check_frame(UINT Frame);



// .... HIER KOMMT EIGENTLICH NOCH MEHR
So ist das ja eigentlich schon mal ganz nett. Die Übersichtlichkeit steigert es aber nicht gerade.
Kann ich die Kommentare auch auslagern?
Hätte das einen Sinn?
Sind die Kommentare vielleicht einfach besser in der Source-Datei aufgehoben?

Dann: Ist es sinnvoll Dateien zu kommentieren? Wenn ja, wann und warum?

Außerdem: Was hat es mit diesen defgroups auf sich? Wie verwendet man sie? Wofür verwendet man sie? Gibt es andere Möglichkeiten, die Dokumentation zu strukturieren?

Ich hoffe ihr könnt mir ein paar dieser Fragen beantworten.
Wenn genügend Antworten kommen könnten wir das fürs Wiki zusammenfassen :)
Bei Fragen einfach an daniel[ät]proggen[Punkt]org
Ich helfe gerne! :)
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.

Benutzeravatar
cloidnerux
Moderator
Beiträge: 3123
Registriert: Fr Sep 26, 2008 4:37 pm
Wohnort: Ram (Gibts wirklich)

Re: Doxygen - Sinnvolle, übersichtliche Verwendung

Beitrag von cloidnerux » Fr Apr 23, 2010 6:47 pm

WO wird kommentiert? In den Headerdateien (die eigentlich FAST alles noch einmal enthalten) oder in den Quelldateien?
Ich würde ein Identische Dokumentation in beiden Dateien anstreben, da man dadurch schneller den Sinn und Funktionsweise einer Funktion erfährt.
Die einen würden in die Header schauen, die anderen in die Quellcodedatei, desswegen ist es sinnvoll beide zu Kommentieren.
WIE wird kommentiert? Ich habe nun schon einige unterschiedliche Varianten gesehen, welche ist die Beste, wenn es eine gibt, und wenn ja, warum?
Doxygen unterstützt meines wissens nach mehrere Kommentararten, was sich aber nur auf die "Einleitung" des Kommentars gilt.
Zudem muss das Kommentar ohne Leerzeile über der betreffenden Funktion oder Variable stehen-
Ich Persönlich würde folgende Art bevorzugen:

Code: Alles auswählen

/// \desc Funktion
/// \param a Ein Parameter
/// \return Ein wert
int Funktion(int a)
{
    //Hier muss noch was gemacht werden...
}
Damit hatt man ersteinmal ein einfacheren Lesefluss, weil die Zeilenanfänge sehr identisch aussehen und den Leser nicht ablenken. Zudem kannst du dadurch eine Unterscheidung zwischen Doxygen-Beschreibung und einem Kommentar oder Hinweis schaffen. Zudem bin ich noch ein wenig von den XML-Kommentaren aus Visual Stdudio geprägt, das die Kommentare Automatisch erzeugt :hrrr:
Dann: Ist es sinnvoll Dateien zu kommentieren? Wenn ja, wann und warum?
Es ist auf jeden Fall sinnvoll, zum einen um die Funktionsweise einer Funktion zu erfahren und zu verstehen und um die Parameter und Rückgabewerte zu kennen. Programmierer die deinen Code nicht kennen können so schnell herausfinden wozu eine Funktion gut ist, und welche Parameter sie erwartet.
Zudem musst du dir dann auch mehr Gedanken über die Funktion und ihre Funktionsweise machen, was die Fehler reduziert, Algorithmen beschleunigt und Denkfehler minimiert und schneller sichtbar macht.
Kann ich die Kommentare auch auslagern?
Für Doxygen nicht, hätte aber auch keinen Sinn, denn Kommentare sollten immer bei der entsprechenden Variable oder Funktion stehen, um schneller Klarheit und Verständiniss zu schaffen.

Ich habe noch nicht viel mit Doxygen gearbeitet, desswegen garantiere ich hier für keine Korrekten Infromationen. Den Teil über Kommentare kann ich aber auch aus den XML-Kommentaren von Visual Studio ziehen. Kommentare sind allgemein sinnvoll und sollten auch immer angwendet werden. Man kann keinem programmierer zumuten, selbst seinen eigenen Quelltext Unkommentiert zu lassen ;)
Redundanz macht wiederholen unnötig.
quod erat expectandum

AnGaiNoR
Beiträge: 212
Registriert: Sa Jul 19, 2008 7:07 pm
Wohnort: Dresden

Re: Doxygen - Sinnvolle, übersichtliche Verwendung

Beitrag von AnGaiNoR » Fr Apr 23, 2010 6:57 pm

In meinen Augen liegt die Stärke von Doxygen auch vor allem in dem gleichnamigen Tool. Damit kannst du nämlich die Dokumentation aus den Quelltexten extrahieren (in HTML, PDF, ...). Die Übersichtlichkeit - zumindest sehe ich das so - wird durch Kommentare eigentlich eher negativ beeinflusst.
Meiner Meinung nach macht eine Dokumentation in Headern am meisten Sinn, da man sich als "Fremdnutzer" ja eher weniger für den Quelltext an sich interessiert.
Physics is like sex: sure, it may give some practical result, but that's not why we do it.
(Richard P. Feynman)

Benutzeravatar
Dirty Oerti
Beiträge: 2229
Registriert: Di Jul 08, 2008 5:05 pm
Wohnort: Thurndorf / Würzburg

Re: Doxygen - Sinnvolle, übersichtliche Verwendung

Beitrag von Dirty Oerti » Fr Apr 23, 2010 7:44 pm

cloidnerux hat geschrieben:Ich würde ein Identische Dokumentation in beiden Dateien anstreben, da man dadurch schneller den Sinn und Funktionsweise einer Funktion erfährt.
Die einen würden in die Header schauen, die anderen in die Quellcodedatei, desswegen ist es sinnvoll beide zu Kommentieren.
Die Argumentation ist verständlich. Blöd ist nur, dass dadurch ein unglaublicher Mehraufwand entsteht.
Ich denke, ich werde jetzt aber wohl erst einmal die Quelldateien kommentieren, da ich diese normalerweise auch zuerst erstelle.
cloidnerux hat geschrieben:Doxygen unterstützt meines wissens nach mehrere Kommentararten, was sich aber nur auf die "Einleitung" des Kommentars gilt.
Da gibt es soweit ich weiß noch mehr. Abgesehen von der Möglichkeit die du angewandt hast kenne ich spontan noch folgendes:

Code: Alles auswählen

/// \fn FUNKTION
/// \brief blub
Sowie nur:

Code: Alles auswählen

/// \brief blub
Natürlich jeweils mit den entsprechenden zusätzlichen Angaben zu Parametern, einer eventuellen ausführlichen Beschreibung und nicht zu vergessen den verschiedenen Kommentareinleitungen (/** z.B. ). Wo liegen da die Unterschiede? Gibt es Unterschiede? Was nimmt man wofür?
cloidnerux hat geschrieben:Es ist auf jeden Fall sinnvoll, zum einen um die Funktionsweise einer Funktion zu erfahren und zu verstehen und um die Parameter und Rückgabewerte zu kennen. Programmierer die deinen Code nicht kennen können so schnell herausfinden wozu eine Funktion gut ist, und welche Parameter sie erwartet.
Zudem musst du dir dann auch mehr Gedanken über die Funktion und ihre Funktionsweise machen, was die Fehler reduziert, Algorithmen beschleunigt und Denkfehler minimiert und schneller sichtbar macht.
Das ist klar, da hast du mich jetzt etwas falsch verstanden.
Man kann mit Doxygen ja nicht nur Funktionen, Variablen und Klassen dokumentieren, sondern auch einer Datei einen eigenen Kommentar zuweisen.

Code: Alles auswählen

/// \file DATEI
/// \brief BLA!
Sind solche Angaben sinnvoll? Bzw in welchen Fällen ist soetwas sinnvoll?
cloidnerux hat geschrieben:Für Doxygen nicht, hätte aber auch keinen Sinn, denn Kommentare sollten immer bei der entsprechenden Variable oder Funktion stehen, um schneller Klarheit und Verständiniss zu schaffen.
So im Nachhinein fällt mir selbst auf, dass es wenig Nutzen hätte, die Kommentare auszulagern.
Ich versuche eben nur eine möglichst gute Gratwanderung zwischen guter Dokumentation und Übersichtlichkeit zu schaffen.

AnGaiNoR hat geschrieben:In meinen Augen liegt die Stärke von Doxygen auch vor allem in dem gleichnamigen Tool. Damit kannst du nämlich die Dokumentation aus den Quelltexten extrahieren (in HTML, PDF, ...).
Das ist schon klar. Die Dokumentation dann zu extrahieren ist sozusagen "The Big Goal" ;)
AnGaiNoR hat geschrieben:Meiner Meinung nach macht eine Dokumentation in Headern am meisten Sinn, da man sich als "Fremdnutzer" ja eher weniger für den Quelltext an sich interessiert.
Das ist auch ein Aspekt. Die Frage ist nur, inwieweit das übersichtlich gestaltet werden kann.
Bei Fragen einfach an daniel[ät]proggen[Punkt]org
Ich helfe gerne! :)
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8861
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Doxygen - Sinnvolle, übersichtliche Verwendung

Beitrag von Xin » Fr Apr 23, 2010 10:17 pm

Dirty Oerti hat geschrieben:Der Kernel ist in C geschrieben. Ein paar Fetzen Assembler sind auch dabei.
Von Assembler hält Doxygen soweit ich weiß nicht viel ;-)
Dirty Oerti hat geschrieben:WO wird kommentiert? In den Headerdateien (die eigentlich FAST alles noch einmal enthalten) oder in den Quelldateien?
Mein aktueller Trend ist wie folgt:

Ich dokumentiere Klassen und Membervariablen in den Header-Dateien.
Die Funktionen dokumentiere ich aber in den Quellcodes aus folgendem Grund: Möchte ich die Klasse verstehen schaue ich in die Dokumentation - dafür schreibe ich sie ja. Schaue ich in die Headerdatei will ich nur einen schnellen Überblick - dann stören mich die Kommentare der Methoden. Bin ich im Quellcode unterteilt die Dokumentation (auch farblich) die Methoden und hilft mir, mich zurecht zu finden.
Dirty Oerti hat geschrieben:WIE wird kommentiert? Ich habe nun schon einige unterschiedliche Varianten gesehen, welche ist die Beste, wenn es eine gibt, und wenn ja, warum?
Welche Varianten stehen Dir denn so groß zur Auswahl?!?
Dirty Oerti hat geschrieben:Dann noch ein zweites WO:
Wie platziere ich die Kommentare am sinnvollsten in den Dateien?
Ich hab das jetzt mal testweise für einen Header gemacht, das würde dann so aussehen:
Was das kommende ist, erkennt Doxygen eigentlich auch von selbst ganz gut.
Dirty Oerti hat geschrieben:So ist das ja eigentlich schon mal ganz nett. Die Übersichtlichkeit steigert es aber nicht gerade.
Kann ich die Kommentare auch auslagern?
Hätte das einen Sinn?
Sind die Kommentare vielleicht einfach besser in der Source-Datei aufgehoben?
Wie gesagt, zu dem Schluss bin ich inzwischen auch gekommen. Nur Klassen und Member müssen nunmal (sofern nicht statisch) weiterhin im Header sein.
Dirty Oerti hat geschrieben:Dann: Ist es sinnvoll Dateien zu kommentieren? Wenn ja, wann und warum?
Ich würde eher Algorithmen dokumentieren (das geht auch extern) oder das Zusammenspiel von Klassen.
Was genau stellst Du Dir denn vor? Dateiformat? Ja. datei.c - "Das ist ein Quellcode"... ähh... nein? ;-)
Dirty Oerti hat geschrieben:Außerdem: Was hat es mit diesen defgroups auf sich? Wie verwendet man sie? Wofür verwendet man sie? Gibt es andere Möglichkeiten, die Dokumentation zu strukturieren?
So wie ich das sehe, definierst Du damit einen eigenständigen Namensraum. Aber nicht einen strukturellen wie in C++, sondern einen semantischen. Zum Beispiel Variablen, die zum Scheduler gehören oder Macros, die Du irgendwie zusammengehören oder zusammenarbeiten.
Das habe ich aber auch noch nie benutzt.... sieht aber interessant aus.
Dirty Oerti hat geschrieben:Wenn genügend Antworten kommen könnten wir das fürs Wiki zusammenfassen :)
Das würde ich sowieso gerne. Doxygen halte ich für ein wichtiges Tool, aber es ist noch klein genug, um in endlicher Zeit eine gute Beschreibung hinzubekommen.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Kerli
Beiträge: 1456
Registriert: So Jul 06, 2008 10:17 am
Wohnort: Österreich
Kontaktdaten:

Re: Doxygen - Sinnvolle, übersichtliche Verwendung

Beitrag von Kerli » Sa Apr 24, 2010 9:17 am

Dirty Oerti hat geschrieben:WO wird kommentiert? In den Headerdateien (die eigentlich FAST alles noch einmal enthalten) oder in den Quelldateien?
Ich halte das so, dass ich in den Headerdateien immer einen Kommentar zu jeder (Member-)Funktion schreibe. Das hat den Sinn das ich dort kurz beschreibe was diese Funktion den eigentlich tun soll und worauf man dabei achten muss. Schließlich will ich ja wenn ich die Funktion verwende nur wissen was sie macht und nicht wie sie das macht. Und dabei interessiert mich die Implementierung dahinter recht wenig. Außerdem ist es so auch möglich eine Dokumentation für weitere Benutzer der eigenen Bibliotheken zu erstellen, ohne dass sie die Sourcefiles betrachten müssen.

Weitere Kommentare zu den Funktionen und eventuelle Details zu Algorithmen kommen dann direkt an die Stelle in der Implementierung wo sie auch hinpassen. So kann ich dann auch zb zwei verschiedene Dokumentationen erstellen lassen. Eine für Benutzer der Bibliothek und eine für Entwickler.

Hier sind beispielsweise der Quellcode und die Dokumentation (Für User) meiner Engine:

http://bazaar.launchpad.net/~tomprogs/g ... e/gewoopi/
http://dl.dropbox.com/u/1279274/www/gew ... index.html
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)

OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at

Antworten