Revision d1564e8a
Von Moritz Bunkus vor etwa 12 Jahren hinzugefügt
| doc/html/ch04s06.html | ||
|---|---|---|
| 1 | 1 |
<html><head> |
| 2 | 2 |
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| 3 |
<title>4.6. Dokumentation erstellen</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Stil-Richtlinien"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.6. Dokumentation erstellen</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="4.6. Dokumentation erstellen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.build-doc"></a>4.6. Dokumentation erstellen</h2></div></div></div><div class="sect2" title="4.6.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.introduction"></a>4.6.1. Einführung</h3></div></div></div><p>Diese Dokumentation ist in <span class="productname">DocBook</span>™ |
|
| 4 |
XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor. |
|
| 5 |
Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen |
|
| 6 |
Editor nutzt, der spezielle Unterstützung für |
|
| 7 |
<span class="productname">DocBook</span>™ mitbringt. Wir empfehlen dafür den |
|
| 8 |
<a class="ulink" href="http://www.xmlmind.com/xmleditor/" target="_top">XMLmind XML |
|
| 9 |
Editor</a>, der bei nicht kommerzieller Nutzung kostenlos |
|
| 10 |
ist.</p></div><div class="sect2" title="4.6.2. Benötigte Software"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.required-software"></a>4.6.2. Benötigte Software</h3></div></div></div><p>Bei <span class="productname">DocBook</span>™ ist Prinzip, dass |
|
| 11 |
ausschließlich die XML-Quelldatei bearbeitet wird. Aus dieser werden |
|
| 12 |
dann mit entsprechenden Stylesheets andere Formate wie PDF oder HTML |
|
| 13 |
erzeugt. Bei kivitendo übernimmt diese Aufgabe das Shell-Script |
|
| 14 |
<span class="command"><strong>scripts/build_doc.sh</strong></span>.</p><p>Das Script benötigt zur Konvertierung verschiedene |
|
| 15 |
Softwarekomponenten, die im normalen kivitendo-Betrieb nicht benötigt |
|
| 16 |
werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> |
|
| 17 |
<a class="ulink" href="http://www.oracle.com/technetwork/java/index.html" target="_top">Java</a> |
|
| 18 |
in einer halbwegs aktuellen Version</p></li><li class="listitem"><p>Das Java-Build-System <a class="ulink" href="http://ant.apache.org/" target="_top">Apache Ant</a> |
|
| 19 |
</p></li><li class="listitem"><p>Das Dokumentations-System Dobudish für |
|
| 20 |
<span class="productname">DocBook</span>™ 4.5, eine Zusammenstellung |
|
| 21 |
diverser Stylesheets und Grafiken zur Konvertierung von |
|
| 22 |
<span class="productname">DocBook</span>™ XML in andere Formate. Das |
|
| 23 |
Paket, das benötigt wird, ist zum Zeitpunkt der |
|
| 24 |
Dokumentationserstellung |
|
| 25 |
<code class="filename">dobudish-nojre-1.1.4.zip</code>, aus auf <a class="ulink" href="http://code.google.com/p/dobudish/downloads/list" target="_top">code.google.com</a> |
|
| 26 |
bereitsteht.</p></li></ul></div><p>Apache Ant sowie ein dazu passendes Java Runtime Environment |
|
| 27 |
sind auf allen gängigen Plattformen verfügbar. Beispiel für |
|
| 28 |
Debian/Ubuntu:</p><pre class="programlisting">apt-get install ant openjdk-7-jre</pre><p>Nach dem Download von Dobudish muss Dobudish im Unterverzeichnis |
|
| 29 |
<code class="filename">doc/build</code> entpackt werden. Beispiel unter der |
|
| 30 |
Annahme, das <span class="productname">Dobudish</span>™ in |
|
| 31 |
<code class="filename">$HOME/Downloads</code> heruntergeladen wurde:</p><pre class="programlisting">cd doc/build |
|
| 32 |
unzip $HOME/Downloads/dobudish-nojre-1.1.4.zip</pre></div><div class="sect2" title="4.6.3. PDFs und HTML-Seiten erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.build"></a>4.6.3. PDFs und HTML-Seiten erstellen</h3></div></div></div><p>Die eigentliche Konvertierung erfolgt nach Installation der |
|
| 33 |
benötigten Software mit einem einfachen Aufruf direkt aus dem |
|
| 34 |
kivitendo-Installationsverzeichnis heraus:</p><pre class="programlisting">./scripts/build_doc.sh</pre></div><div class="sect2" title="4.6.4. Einchecken in das Git-Repository"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.repository"></a>4.6.4. Einchecken in das Git-Repository</h3></div></div></div><p>Sowohl die XML-Datei als auch die erzeugten PDF- und |
|
| 35 |
HTML-Dateien sind Bestandteil des Git-Repositories. Daraus folgt, dass |
|
| 36 |
nach Änderungen am XML die PDF- und HTML-Dokumente ebenfalls gebaut |
|
| 37 |
und alles zusammen in einem Commit eingecheckt werden sollten.</p><p>Die "<code class="filename">dobudish</code>"-Verzeichnisse bzw. |
|
| 38 |
symbolischen Links gehören hingegen nicht in das Repository.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">4.5. Stil-Richtlinien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html> |
|
| 3 |
<title>4.6. Stil-Richtlinien</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Die kivitendo-Test-Suite"><link rel="next" href="ch04s07.html" title="4.7. Dokumentation erstellen"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.6. Stil-Richtlinien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.6. Stil-Richtlinien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.style-guide"></a>4.6. Stil-Richtlinien</h2></div></div></div><p>Die folgenden Regeln haben das Ziel, den Code möglichst gut les- |
|
| 4 |
und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich |
|
| 5 |
eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden |
|
| 6 |
wird (Stichworte "Klammern" oder "Hash-Keys").</p><p>Diese Regeln sind keine Schikane sondern erleichtern allen das |
|
| 7 |
Leben!</p><p>Jeder, der einen Patch schickt, sollte seinen Code vorher |
|
| 8 |
überprüfen. Einige der Regeln lassen sich automatisch überprüfen, andere |
|
| 9 |
nicht.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Es werden keine echten Tabs sondern Leerzeichen |
|
| 10 |
verwendet.</p></li><li class="listitem"><p>Die Einrückung beträgt zwei Leerzeichen. Beispiel:</p><pre class="programlisting">foreach my $row (@data) {
|
|
| 11 |
if ($flag) {
|
|
| 12 |
# do something with $row |
|
| 13 |
} |
|
| 14 |
|
|
| 15 |
if ($use_modules) {
|
|
| 16 |
$row->{modules} = MODULE->retrieve(
|
|
| 17 |
id => $row->{id},
|
|
| 18 |
date => $use_now ? localtime() : $row->{time},
|
|
| 19 |
); |
|
| 20 |
} |
|
| 21 |
|
|
| 22 |
$report->add($row); |
|
| 23 |
}</pre></li><li class="listitem"><p>Öffnende geschweifte Klammern befinden sich auf der gleichen |
|
| 24 |
Zeile wie der letzte Befehl. Beispiele:</p><pre class="programlisting">sub debug {
|
|
| 25 |
... |
|
| 26 |
}</pre><p>oder</p><pre class="programlisting">if ($form->{item_rows} > 0) {
|
|
| 27 |
... |
|
| 28 |
}</pre></li><li class="listitem"><p>Schließende geschweifte Klammern sind so weit eingerückt wie |
|
| 29 |
der Befehl / die öffnende schließende Klammer, die den Block |
|
| 30 |
gestartet hat, und nicht auf der Ebene des Inhalts. Die gleichen |
|
| 31 |
Beispiele wie bei 3. gelten.</p></li><li class="listitem"><p>Die Wörter "<code class="function">else</code>", |
|
| 32 |
"<code class="function">elsif</code>", "<code class="function">while</code>" befinden |
|
| 33 |
sich auf der gleichen Zeile wie schließende geschweifte Klammern. |
|
| 34 |
Beispiele:</p><pre class="programlisting">if ($form->{sum} > 1000) {
|
|
| 35 |
... |
|
| 36 |
} elsif ($form->{sum} > 0) {
|
|
| 37 |
... |
|
| 38 |
} else {
|
|
| 39 |
... |
|
| 40 |
} |
|
| 41 |
|
|
| 42 |
do {
|
|
| 43 |
... |
|
| 44 |
} until ($a > 0);</pre></li><li class="listitem"><p>Parameter von Funktionsaufrufen müssen mit runden Klammern |
|
| 45 |
versehen werden. Davon nicht betroffen sind interne Perl-Funktionen, |
|
| 46 |
und grep-ähnliche Operatoren. Beispiel:</p><pre class="programlisting">$main::lxdebug->message("Could not find file.");
|
|
| 47 |
%options = map { $_ => 1 } grep { !/^#/ } @config_file;</pre></li><li class="listitem"><p>Verschiedene Klammern, Ihre Ausdrücke und Leerzeichen:</p><p>Generell gilt: Hashkeys und Arrayindices sollten nicht durch
|
|
| 48 |
Leerzeichen abgesetzt werden. Logische Klammerungen ebensowenig, |
|
| 49 |
Blöcke schon. Beispiel:</p><pre class="programlisting">if (($form->{debug} == 1) && ($form->{sum} - 100 < 0)) {
|
|
| 50 |
... |
|
| 51 |
} |
|
| 52 |
|
|
| 53 |
$array[$i + 1] = 4; |
|
| 54 |
$form->{sum} += $form->{"row_$i"};
|
|
| 55 |
$form->{ $form->{index} } += 1;
|
|
| 56 |
|
|
| 57 |
map { $form->{sum} += $form->{"row_$_"} } 1..$rowcount;</pre></li><li class="listitem"><p>Mehrzeilige Befehle</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Werden die Parameter eines Funktionsaufrufes auf mehrere
|
|
| 58 |
Zeilen aufgeteilt, so sollten diese bis zu der Spalte eingerückt |
|
| 59 |
werden, in der die ersten Funktionsparameter in der ersten Zeile |
|
| 60 |
stehen. Beispiel:</p><pre class="programlisting">$sth = $dbh->prepare("SELECT * FROM some_table WHERE col = ?",
|
|
| 61 |
$form->{some_col_value});</pre></li><li class="listitem"><p>Ein Spezialfall ist der ternäre Oprator "?:", der am
|
|
| 62 |
besten in einer übersichtlichen Tabellenstruktur organisiert |
|
| 63 |
wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form->{"row_$i"} ? $i
|
|
| 64 |
: $form->{oldcount} ? $form->{oldcount} + 1
|
|
| 65 |
: $form->{rowcount} - $form->{rowbase};</pre></li></ol></div></li><li class="listitem"><p>Kommentare</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Kommentare, die alleine in einer Zeile stehen, sollten
|
|
| 66 |
soweit wie der Code eingerückt sein.</p></li><li class="listitem"><p>Seitliche hängende Kommentare sollten einheitlich |
|
| 67 |
formatiert werden.</p></li><li class="listitem"><p>Sämtliche Kommentare und Sonstiges im Quellcode ist bitte |
|
| 68 |
auf Englisch zu verfassen. So wie ich keine Lust habe, |
|
| 69 |
französischen Quelltext zu lesen, sollte auch der kivitendo |
|
| 70 |
Quelltext für nicht-Deutschsprachige lesbar sein. |
|
| 71 |
Beispiel:</p><pre class="programlisting">my $found = 0; |
|
| 72 |
while (1) {
|
|
| 73 |
last if $found; |
|
| 74 |
|
|
| 75 |
# complicated check |
|
| 76 |
$found = 1 if // |
|
| 77 |
} |
|
| 78 |
|
|
| 79 |
$i = 0 # initialize $i |
|
| 80 |
$n = $i; # save $i |
|
| 81 |
$i *= $const; # do something crazy |
|
| 82 |
$i = $n; # recover $i</pre></li></ol></div></li><li class="listitem"><p>Hashkeys sollten nur in Anführungszeichen stehen, wenn die |
|
| 83 |
Interpolation gewünscht ist. Beispiel:</p><pre class="programlisting">$form->{sum} = 0;
|
|
| 84 |
$form->{"row_$i"} = $form->{"row_$i"} - 5;
|
|
| 85 |
$some_hash{42} = 54;</pre></li><li class="listitem"><p>Die maximale Zeilenlänge ist nicht beschränkt. Zeilenlängen
|
|
| 86 |
unterhalb von 79 Zeichen helfen unter bestimmten Bedingungen, aber |
|
| 87 |
wenn die Lesbarkeit unter kurzen Zeilen leidet (wie zum Biespiel in |
|
| 88 |
grossen Tabellen), dann ist Lesbarkeit vorzuziehen.</p><p>Als Beispiel sei die Funktion |
|
| 89 |
<code class="function">print_options</code> aus |
|
| 90 |
<code class="filename">bin/mozilla/io.pl</code> angeführt.</p></li><li class="listitem"><p>Trailing Whitespace, d.h. Leerzeichen am Ende von Zeilen sind |
|
| 91 |
unerwünscht. Sie führen zu unnötigen Whitespaceänderungen, die diffs |
|
| 92 |
verfälschen.</p><p>Emacs und vim haben beide recht einfache Methoden zur |
|
| 93 |
Entfernung von trailing whitespace. Emacs kennt das Kommande |
|
| 94 |
<span class="command"><strong>nuke-trailing-whitespace</strong></span>, vim macht das gleiche |
|
| 95 |
manuell über <code class="literal">:%s/\s\+$//e</code> Mit <code class="literal">:au |
|
| 96 |
BufWritePre * :%s/\s\+$//e</code> wird das an Speichern |
|
| 97 |
gebunden.</p></li><li class="listitem"><p>Es wird kein <span class="command"><strong>perltidy</strong></span> verwendet.</p><p>In der Vergangenheit wurde versucht, |
|
| 98 |
<span class="command"><strong>perltidy</strong></span> zu verwenden, um einen einheitlichen |
|
| 99 |
Stil zu erlangen. Es hat sich aber gezeigt, dass |
|
| 100 |
<span class="command"><strong>perltidy</strong></span>s sehr eigenwilliges Verhalten, was |
|
| 101 |
Zeilenumbrüche angeht, oftmals gut formatierten Code zerstört. Für |
|
| 102 |
den Interessierten sind hier die |
|
| 103 |
<span class="command"><strong>perltidy</strong></span>-Optionen, die grob den beschriebenen |
|
| 104 |
Richtlinien entsprechen:</p><pre class="programlisting">-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm |
|
| 105 |
-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79 |
|
| 106 |
-lp -vt=1 -vtc=1</pre></li><li class="listitem"><p> |
|
| 107 |
<code class="varname">STDERR</code> ist tabu. Unkonditionale |
|
| 108 |
Debugmeldungen auch.</p><p>kivitendo bietet mit dem Modul <code class="classname">LXDebug</code> |
|
| 109 |
einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen |
|
| 110 |
Grund, nach <code class="varname">STDERR</code> zu schreiben.</p><p>Die <code class="classname">LXDebug</code>-Methode |
|
| 111 |
"<code class="function">message</code>" nimmt als ersten Paramter außerdem |
|
| 112 |
eine Flagmaske, für die die Meldung angezeigt wird, wobei "0" immer |
|
| 113 |
angezeigt wird. Solche Meldungen sollten nicht eingecheckt werden |
|
| 114 |
und werden in den meisten Fällen auch vom Repository |
|
| 115 |
zurückgewiesen.</p></li><li class="listitem"><p>Alle neuen Module müssen use strict verwenden.</p><p> |
|
| 116 |
<code class="varname">$form</code>, <code class="varname">$auth</code>, |
|
| 117 |
<code class="varname">$locale</code>, <code class="varname">$lxdebug</code> und |
|
| 118 |
<code class="varname">%myconfig</code> werden derzeit aus dem main package |
|
| 119 |
importiert (siehe <a class="xref" href="ch04.html#devel.globals" title="4.1. Globale Variablen">Globale Variablen</a>. Alle anderen |
|
| 120 |
Konstrukte sollten lexikalisch lokal gehalten werden.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.5. Die kivitendo-Test-Suite </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.7. Dokumentation erstellen</td></tr></table></div></body></html> |
|
Auch abrufbar als: Unified diff
Doku: Test-Doku aus t/README in die Haupt-Doku überführt & erweitert