projekt kivitendo

    <sect1 id="devel.testsuite">

      <title>Die kivitendo-Test-Suite</title>

      <sect2 id="devel.testsuite.intro">

        <title>Einführung</title>

        <para>kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul <literal>Test::More</literal>.</para>

        <para>Die grundlegenden Fakten sind:</para>

        <itemizedlist>

          <listitem><para>Alle Tests liegen im Unterverzeichnis <filename>t/</filename>.</para></listitem>

          <listitem><para>Ein Script (bzw. ein Test) in <filename>f/</filename> enthält einen oder mehrere Testfälle.</para></listitem>

          <listitem><para>Alle Dateinamen von Tests enden auf <literal>.t</literal>. Es sind selbstständig ausführbare Perl-Scripte.</para></listitem>

          <listitem><para>Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in <filename>f/</filename>, deren

          Dateiname auf <literal>.t</literal> endet.</para></listitem>

        </itemizedlist>

      </sect2>

      <sect2 id="devel.testsuite.prerequisites">

        <title>Voraussetzungen</title>

        <para>Für die Ausführung werden neben den für kivitendo eh schon benötigten Module noch weitere Perl-Module benötigt. Diese sind:</para>

        <itemizedlist>

          <listitem><para><literal>Test::Deep</literal> (Debian-Paketname: <literal>libtest-deep-perl</literal>; Fedora Core:

          <literal>perl-Test-Deep</literal>; openSuSE: <literal>perl-Test-Deep</literal>)</para></listitem>

        </itemizedlist>

      </sect2>

      <sect2 id="devel.testsuite.execution">

        <title>

          Existierende Tests ausführen

        </title>

        <para>Es gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder, man lässt alle Tests auf einmal ausführen, oder man führt

        gezielt einzelne Scripte aus. Für beide Fälle gibt es das Helferscript <filename>t/test.sh</filename>.</para>

        <para>Will man die komplette Test-Suite ausführen, so muss man einfach nur <filename>t/test.sh</filename> ohne weitere Parameter aus

        dem kivitendo-Basisverzeichnis heraus ausführen.</para>

        <para>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an <filename>t/test.sh</filename>. Beispielsweise:</para>

        <programlisting>t/test.sh t/form/format_amount.t t/background_job/known_jobs.t</programlisting>

      </sect2>

      <sect2 id="devel.testsuite.meaning_of_scripts">

        <title>

          Bedeutung der verschiedenen Test-Scripte

        </title>

        <para>Die Test-Suite umfasst Tests sowohl für Funktionen als auch für Programmierstil. Einige besonders zu erwähnende, weil auch

        während der Entwicklung nützliche Tests sind:</para>

        <itemizedlist>

          <listitem><para><filename>t/001compile.t</filename> -- compiliert alle Quelldateien und bricht bei Fehlern sofort ab</para></listitem>

          <listitem><para><filename>t/002goodperl.t</filename> -- überprüft alle Perl-Dateien auf Anwesenheit von '<literal>use strict</literal>'-Anweisungen</para></listitem>

          <listitem><para><filename>t/003safesys.t</filename> -- überprüft Aufrufe von <function>system()</function> und <function>exec()</function> auf Gültigkeit</para></listitem>

          <listitem><para><filename>t/005no_tabs.t</filename> -- überprüft, ob Dateien Tab-Zeichen enthalten</para></listitem>

          <listitem><para><filename>t/006spelling.t</filename> -- sucht nach häufigen Rechtschreibfehlern</para></listitem>

          <listitem><para><filename>t/011pod.t</filename> -- überprüft die Syntax von Dokumentation im POD-Format auf Gültigkeit</para></listitem>

        </itemizedlist>

        <para>Weitere Test-Scripte überprüfen primär die Funktionsweise einzelner Funktionen und Module.</para>

      </sect2>

      <sect2 id="devel.testsuite.create_new">

        <title>

          Neue Test-Scripte erstellen

        </title>

        <para>Es wird sehr gern gesehen, wenn neue Funktionalität auch gleich mit einem Test-Script abgesichert wird. Auch bestehende

        Funktion darf und soll ausdrücklich nachträglich mit Test-Scripten abgesichert werden.</para>

        <sect3 id="devel.testsuite.ideas_for_non_function_tests">

          <title>

            Ideen für neue Test-Scripte, die keine konkreten Funktionen testen

          </title>

          <para> Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:</para>

          <itemizedlist>

            <listitem><para>Überprüfung auf fehlende symbolische Links</para></listitem>

            <listitem><para>Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)</para></listitem>

            <listitem><para>Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)</para></listitem>

            <listitem><para>Überprüfung auf Leerzeichen am Ende von Zeilen</para></listitem>

            <listitem><para>Test, ob alle zu übersetzenden Strings in <filename>locale/de/all</filename> vorhanden sind</para></listitem>

            <listitem><para>Test, ob alle Webseiten-Templates in <filename>templates/webpages</filename> mit vom Perl-Modul <literal>Template</literal> compiliert werden können</para></listitem>

          </itemizedlist>

        </sect3>

        <sect3 id="devel.testsuite.directory_and_test_names">

          <title>

            Konvention für Verzeichnis- und Dateinamen

          </title>

          <para>Es gibt momentan eine wenige Richtlinien, wie Test-Scripte zu benennen sind. Bitte die folgenden Punkte als Richtlinie betrachten und ihnen soweit es geht folgen:</para>

          <itemizedlist>

            <listitem><para>Die Dateiendung muss <filename>.t</filename> lauten.</para></listitem>

            <listitem><para>Namen sind englisch, komplett klein geschrieben und einzelne Wörter mit Unterstrichten getrennt (beispielsweise

            <filename>bad_function_params.t</filename>).</para></listitem>

            <listitem><para>Unterverzeichnisse sollten grob nach dem Themenbereich benannt sind, mit dem sich die Scripte darin befassen

            (beispielsweise <filename>background_jobs</filename> für Tests rund um Hintergrund-Jobs).</para></listitem>

            <listitem><para>Test-Scripte sollten einen überschaubaren Bereich von Funktionalität testen, der logisch zusammenhängend ist

            (z.B. nur Tests für eine einzelne Funktion in einem Modul). Lieber mehrere Test-Scripte schreiben.</para></listitem>

          </itemizedlist>

        </sect3>

        <sect3 id="devel.testsuite.minimal_example">

          <title>

            Minimales Skelett für eigene Scripte

          </title>

          <para>Der folgenden Programmcode enthält das kleinstmögliche Testscript und kann als Ausgangspunkt für eigene Tests verwendet werden:</para>

          <programlisting>use Test::More tests =&gt; 0;

use lib 't';

use Support::TestSetup;

Support::TestSetup::login();</programlisting>

          <para>Wird eine vollständig initialisierte kivitendo-Umgebung benötigt (Stichwort: alle globalen Variablen wie

          <varname>$::auth</varname>, <varname>$::form</varname> oder <varname>$::lxdebug</varname>), so muss in der Konfigurationsdatei

          <filename>config/kivitendo.conf</filename> im Abschnitt <literal>testing.login</literal> ein gültiger Login-Name eingetragen

          sein. Dieser wird für die Datenbankverbindung benötigt.</para>

          <para>Wir keine vollständig initialisierte Umgebung benötigt, so kann die letzte Zeile <code>Support::TestSetup::login();</code>

          weggelassen werden, was die Ausführungszeit des Scripts leicht verringert.</para>

        </sect3>

      </sect2>

    </sect1>

   <title>4.4. Translations and languages</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="ch04s03.html" title="4.3. SQL-Upgradedateien"><link rel="next" href="ch04s05.html" title="4.5. Die kivitendo-Test-Suite"></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.4. Translations and languages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a>&nbsp;</td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="ch04s05.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.4. Translations and languages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="translations-languages"></a>4.4. Translations and languages</h2></div></div></div><div class="sect2" title="4.4.1. Introduction"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.introduction"></a>4.4.1. Introduction</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="../../../../system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Dieser Abschnitt ist in Englisch geschrieben, um

              want to keep this safe somewhere.</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="ch04s05.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. SQL-Upgradedateien&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top">&nbsp;4.5. Die kivitendo-Test-Suite</td></tr></table></div></body></html>

   <title>4.5. Die kivitendo-Test-Suite</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="ch04s04.html" title="4.4. Translations and languages"><link rel="next" href="ch04s06.html" title="4.6. 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.5. Die kivitendo-Test-Suite</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a>&nbsp;</td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="ch04s06.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.5. Die kivitendo-Test-Suite"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.testsuite"></a>4.5. Die kivitendo-Test-Suite</h2></div></div></div><div class="sect2" title="4.5.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.intro"></a>4.5.1. Einführung</h3></div></div></div><p>kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul <code class="literal">Test::More</code>.</p><p>Die grundlegenden Fakten sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Alle Tests liegen im Unterverzeichnis <code class="filename">t/</code>.</p></li><li class="listitem"><p>Ein Script (bzw. ein Test) in <code class="filename">f/</code> enthält einen oder mehrere Testfälle.</p></li><li class="listitem"><p>Alle Dateinamen von Tests enden auf <code class="literal">.t</code>. Es sind selbstständig ausführbare Perl-Scripte.</p></li><li class="listitem"><p>Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in <code class="filename">f/</code>, deren

          Dateiname auf <code class="literal">.t</code> endet.</p></li></ul></div></div><div class="sect2" title="4.5.2. Voraussetzungen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.prerequisites"></a>4.5.2. Voraussetzungen</h3></div></div></div><p>Für die Ausführung werden neben den für kivitendo eh schon benötigten Module noch weitere Perl-Module benötigt. Diese sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>

                     <code class="literal">Test::Deep</code> (Debian-Paketname: <code class="literal">libtest-deep-perl</code>; Fedora Core:

          <code class="literal">perl-Test-Deep</code>; openSuSE: <code class="literal">perl-Test-Deep</code>)</p></li></ul></div></div><div class="sect2" title="4.5.3. Existierende Tests ausführen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.execution"></a>4.5.3. 

          Existierende Tests ausführen

        </h3></div></div></div><p>Es gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder, man lässt alle Tests auf einmal ausführen, oder man führt

        gezielt einzelne Scripte aus. Für beide Fälle gibt es das Helferscript <code class="filename">t/test.sh</code>.</p><p>Will man die komplette Test-Suite ausführen, so muss man einfach nur <code class="filename">t/test.sh</code> ohne weitere Parameter aus

        dem kivitendo-Basisverzeichnis heraus ausführen.</p><p>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an <code class="filename">t/test.sh</code>. Beispielsweise:</p><pre class="programlisting">t/test.sh t/form/format_amount.t t/background_job/known_jobs.t</pre></div><div class="sect2" title="4.5.4. Bedeutung der verschiedenen Test-Scripte"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.meaning_of_scripts"></a>4.5.4. 

          Bedeutung der verschiedenen Test-Scripte

        </h3></div></div></div><p>Die Test-Suite umfasst Tests sowohl für Funktionen als auch für Programmierstil. Einige besonders zu erwähnende, weil auch

        während der Entwicklung nützliche Tests sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>

                     <code class="filename">t/001compile.t</code> -- compiliert alle Quelldateien und bricht bei Fehlern sofort ab</p></li><li class="listitem"><p>

                     <code class="filename">t/002goodperl.t</code> -- überprüft alle Perl-Dateien auf Anwesenheit von '<code class="literal">use strict</code>'-Anweisungen</p></li><li class="listitem"><p>

                     <code class="filename">t/003safesys.t</code> -- überprüft Aufrufe von <code class="function">system()</code> und <code class="function">exec()</code> auf Gültigkeit</p></li><li class="listitem"><p>

                     <code class="filename">t/005no_tabs.t</code> -- überprüft, ob Dateien Tab-Zeichen enthalten</p></li><li class="listitem"><p>

                     <code class="filename">t/006spelling.t</code> -- sucht nach häufigen Rechtschreibfehlern</p></li><li class="listitem"><p>

                     <code class="filename">t/011pod.t</code> -- überprüft die Syntax von Dokumentation im POD-Format auf Gültigkeit</p></li></ul></div><p>Weitere Test-Scripte überprüfen primär die Funktionsweise einzelner Funktionen und Module.</p></div><div class="sect2" title="4.5.5. Neue Test-Scripte erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.create_new"></a>4.5.5. 

          Neue Test-Scripte erstellen

        </h3></div></div></div><p>Es wird sehr gern gesehen, wenn neue Funktionalität auch gleich mit einem Test-Script abgesichert wird. Auch bestehende

        Funktion darf und soll ausdrücklich nachträglich mit Test-Scripten abgesichert werden.</p><div class="sect3" title="4.5.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen testen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.ideas_for_non_function_tests"></a>4.5.5.1. 

            Ideen für neue Test-Scripte, die keine konkreten Funktionen testen

          </h4></div></div></div><p> Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Überprüfung auf fehlende symbolische Links</p></li><li class="listitem"><p>Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)</p></li><li class="listitem"><p>Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)</p></li><li class="listitem"><p>Überprüfung auf Leerzeichen am Ende von Zeilen</p></li><li class="listitem"><p>Test, ob alle zu übersetzenden Strings in <code class="filename">locale/de/all</code> vorhanden sind</p></li><li class="listitem"><p>Test, ob alle Webseiten-Templates in <code class="filename">templates/webpages</code> mit vom Perl-Modul <code class="literal">Template</code> compiliert werden können</p></li></ul></div></div><div class="sect3" title="4.5.5.2. Konvention für Verzeichnis- und Dateinamen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.directory_and_test_names"></a>4.5.5.2. 

            Konvention für Verzeichnis- und Dateinamen

          </h4></div></div></div><p>Es gibt momentan eine wenige Richtlinien, wie Test-Scripte zu benennen sind. Bitte die folgenden Punkte als Richtlinie betrachten und ihnen soweit es geht folgen:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Die Dateiendung muss <code class="filename">.t</code> lauten.</p></li><li class="listitem"><p>Namen sind englisch, komplett klein geschrieben und einzelne Wörter mit Unterstrichten getrennt (beispielsweise

            <code class="filename">bad_function_params.t</code>).</p></li><li class="listitem"><p>Unterverzeichnisse sollten grob nach dem Themenbereich benannt sind, mit dem sich die Scripte darin befassen

            (beispielsweise <code class="filename">background_jobs</code> für Tests rund um Hintergrund-Jobs).</p></li><li class="listitem"><p>Test-Scripte sollten einen überschaubaren Bereich von Funktionalität testen, der logisch zusammenhängend ist

            (z.B. nur Tests für eine einzelne Funktion in einem Modul). Lieber mehrere Test-Scripte schreiben.</p></li></ul></div></div><div class="sect3" title="4.5.5.3. Minimales Skelett für eigene Scripte"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.minimal_example"></a>4.5.5.3. 

            Minimales Skelett für eigene Scripte

          </h4></div></div></div><p>Der folgenden Programmcode enthält das kleinstmögliche Testscript und kann als Ausgangspunkt für eigene Tests verwendet werden:</p><pre class="programlisting">use Test::More tests =&gt; 0;

use lib 't';

use Support::TestSetup;

Support::TestSetup::login();</pre><p>Wird eine vollständig initialisierte kivitendo-Umgebung benötigt (Stichwort: alle globalen Variablen wie

          <code class="varname">$::auth</code>, <code class="varname">$::form</code> oder <code class="varname">$::lxdebug</code>), so muss in der Konfigurationsdatei

          <code class="filename">config/kivitendo.conf</code> im Abschnitt <code class="literal">testing.login</code> ein gültiger Login-Name eingetragen

          sein. Dieser wird für die Datenbankverbindung benötigt.</p><p>Wir keine vollständig initialisierte Umgebung benötigt, so kann die letzte Zeile <code class="code">Support::TestSetup::login();</code>

          weggelassen werden, was die Ausführungszeit des Scripts leicht verringert.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="ch04s06.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.4. Translations and languages&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top">&nbsp;4.6. Stil-Richtlinien</td></tr></table></div></body></html>

   <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>&nbsp;</td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right">&nbsp;<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-

      und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich

      eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden

      wird (Stichworte "Klammern" oder "Hash-Keys").</p><p>Diese Regeln sind keine Schikane sondern erleichtern allen das

      Leben!</p><p>Jeder, der einen Patch schickt, sollte seinen Code vorher

      überprüfen. Einige der Regeln lassen sich automatisch überprüfen, andere

      nicht.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Es werden keine echten Tabs sondern Leerzeichen

          verwendet.</p></li><li class="listitem"><p>Die Einrückung beträgt zwei Leerzeichen. Beispiel:</p><pre class="programlisting">foreach my $row (@data) {

  if ($flag) {

    # do something with $row

  }

  if ($use_modules) {

    $row->{modules} = MODULE->retrieve(

      id   => $row->{id},

      date => $use_now ? localtime() : $row->{time},

    );

  }

  $report->add($row);

}</pre></li><li class="listitem"><p>Öffnende geschweifte Klammern befinden sich auf der gleichen

          Zeile wie der letzte Befehl. Beispiele:</p><pre class="programlisting">sub debug {

  ...

}</pre><p>oder</p><pre class="programlisting">if ($form-&gt;{item_rows} &gt; 0) {

  ...

}</pre></li><li class="listitem"><p>Schließende geschweifte Klammern sind so weit eingerückt wie

          der Befehl / die öffnende schließende Klammer, die den Block

          gestartet hat, und nicht auf der Ebene des Inhalts. Die gleichen

          Beispiele wie bei 3. gelten.</p></li><li class="listitem"><p>Die Wörter "<code class="function">else</code>",

          "<code class="function">elsif</code>", "<code class="function">while</code>" befinden

          sich auf der gleichen Zeile wie schließende geschweifte Klammern.

          Beispiele:</p><pre class="programlisting">if ($form-&gt;{sum} &gt; 1000) {

  ...

} elsif ($form->{sum} > 0) {

  ...

} else {

  ...

}

do {

  ...

} until ($a &gt; 0);</pre></li><li class="listitem"><p>Parameter von Funktionsaufrufen müssen mit runden Klammern

          versehen werden. Davon nicht betroffen sind interne Perl-Funktionen,

          und grep-ähnliche Operatoren. Beispiel:</p><pre class="programlisting">$main::lxdebug-&gt;message("Could not find file.");

%options = map { $_ =&gt; 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

          Leerzeichen abgesetzt werden. Logische Klammerungen ebensowenig,

          Blöcke schon. Beispiel:</p><pre class="programlisting">if (($form-&gt;{debug} == 1) &amp;&amp; ($form-&gt;{sum} - 100 &lt; 0)) {

  ...

}

$array[$i + 1]             = 4;

$form->{sum}              += $form->{"row_$i"};

$form->{ $form->{index} } += 1;

map { $form-&gt;{sum} += $form-&gt;{"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

              Zeilen aufgeteilt, so sollten diese bis zu der Spalte eingerückt

              werden, in der die ersten Funktionsparameter in der ersten Zeile

              stehen. Beispiel:</p><pre class="programlisting">$sth = $dbh-&gt;prepare("SELECT * FROM some_table WHERE col = ?",

                    $form-&gt;{some_col_value});</pre></li><li class="listitem"><p>Ein Spezialfall ist der ternäre Oprator "?:", der am

              besten in einer übersichtlichen Tabellenstruktur organisiert

              wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form-&gt;{"row_$i"} ? $i

             : $form->{oldcount} ? $form->{oldcount} + 1

             :                     $form-&gt;{rowcount} - $form-&gt;{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

              soweit wie der Code eingerückt sein.</p></li><li class="listitem"><p>Seitliche hängende Kommentare sollten einheitlich

              formatiert werden.</p></li><li class="listitem"><p>Sämtliche Kommentare und Sonstiges im Quellcode ist bitte

              auf Englisch zu verfassen. So wie ich keine Lust habe,

              französischen Quelltext zu lesen, sollte auch der kivitendo

              Quelltext für nicht-Deutschsprachige lesbar sein.

              Beispiel:</p><pre class="programlisting">my $found = 0;

while (1) {

  last if $found;

  # complicated check

  $found = 1 if //

}

$i  = 0        # initialize $i

$n  = $i;      # save $i

$i *= $const;  # do something crazy

$i  = $n;      # recover $i</pre></li></ol></div></li><li class="listitem"><p>Hashkeys sollten nur in Anführungszeichen stehen, wenn die

          Interpolation gewünscht ist. Beispiel:</p><pre class="programlisting">$form-&gt;{sum}      = 0;

$form->{"row_$i"} = $form->{"row_$i"} - 5;

$some_hash{42}    = 54;</pre></li><li class="listitem"><p>Die maximale Zeilenlänge ist nicht beschränkt. Zeilenlängen

          unterhalb von 79 Zeichen helfen unter bestimmten Bedingungen, aber

          wenn die Lesbarkeit unter kurzen Zeilen leidet (wie zum Biespiel in

          grossen Tabellen), dann ist Lesbarkeit vorzuziehen.</p><p>Als Beispiel sei die Funktion

          <code class="function">print_options</code> aus

          <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

          unerwünscht. Sie führen zu unnötigen Whitespaceänderungen, die diffs

          verfälschen.</p><p>Emacs und vim haben beide recht einfache Methoden zur

          Entfernung von trailing whitespace. Emacs kennt das Kommande

          <span class="command"><strong>nuke-trailing-whitespace</strong></span>, vim macht das gleiche

          manuell über <code class="literal">:%s/\s\+$//e</code> Mit <code class="literal">:au

          BufWritePre * :%s/\s\+$//e</code> wird das an Speichern

          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,

          <span class="command"><strong>perltidy</strong></span> zu verwenden, um einen einheitlichen

          Stil zu erlangen. Es hat sich aber gezeigt, dass

          <span class="command"><strong>perltidy</strong></span>s sehr eigenwilliges Verhalten, was

          Zeilenumbrüche angeht, oftmals gut formatierten Code zerstört. Für

          den Interessierten sind hier die

          <span class="command"><strong>perltidy</strong></span>-Optionen, die grob den beschriebenen

          Richtlinien entsprechen:</p><pre class="programlisting">-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm

-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79

-lp -vt=1 -vtc=1</pre></li><li class="listitem"><p>

                  <code class="varname">STDERR</code> ist tabu. Unkonditionale

          Debugmeldungen auch.</p><p>kivitendo bietet mit dem Modul <code class="classname">LXDebug</code>

          einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen

          Grund, nach <code class="varname">STDERR</code> zu schreiben.</p><p>Die <code class="classname">LXDebug</code>-Methode

          "<code class="function">message</code>" nimmt als ersten Paramter außerdem

          eine Flagmaske, für die die Meldung angezeigt wird, wobei "0" immer

          angezeigt wird. Solche Meldungen sollten nicht eingecheckt werden

          und werden in den meisten Fällen auch vom Repository

          zurückgewiesen.</p></li><li class="listitem"><p>Alle neuen Module müssen use strict verwenden.</p><p>

                  <code class="varname">$form</code>, <code class="varname">$auth</code>,

          <code class="varname">$locale</code>, <code class="varname">$lxdebug</code> und

          <code class="varname">%myconfig</code> werden derzeit aus dem main package

          importiert (siehe <a class="xref" href="ch04.html#devel.globals" title="4.1. Globale Variablen">Globale Variablen</a>. Alle anderen

          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>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="ch04s07.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.5. Die kivitendo-Test-Suite&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top">&nbsp;4.7. Dokumentation erstellen</td></tr></table></div></body></html>

<html><head>

      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

   <title>4.7. 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="ch04s06.html" title="4.6. 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.7. Dokumentation erstellen</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a>&nbsp;</td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right">&nbsp;</td></tr></table><hr></div><div class="sect1" title="4.7. Dokumentation erstellen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.build-doc"></a>4.7. Dokumentation erstellen</h2></div></div></div><div class="sect2" title="4.7.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.introduction"></a>4.7.1. Einführung</h3></div></div></div><p>Diese Dokumentation ist in <span class="productname">DocBook</span>™

        XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor.

        Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen

        Editor nutzt, der spezielle Unterstützung für

        <span class="productname">DocBook</span>™ mitbringt. Wir empfehlen dafür den

        <a class="ulink" href="http://www.xmlmind.com/xmleditor/" target="_top">XMLmind XML

        Editor</a>, der bei nicht kommerzieller Nutzung kostenlos

        ist.</p></div><div class="sect2" title="4.7.2. Benötigte Software"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.required-software"></a>4.7.2. Benötigte Software</h3></div></div></div><p>Bei <span class="productname">DocBook</span>™ ist Prinzip, dass

        ausschließlich die XML-Quelldatei bearbeitet wird. Aus dieser werden

        dann mit entsprechenden Stylesheets andere Formate wie PDF oder HTML

        erzeugt. Bei kivitendo übernimmt diese Aufgabe das Shell-Script

        <span class="command"><strong>scripts/build_doc.sh</strong></span>.</p><p>Das Script benötigt zur Konvertierung verschiedene

        Softwarekomponenten, die im normalen kivitendo-Betrieb nicht benötigt

        werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>

                     <a class="ulink" href="http://www.oracle.com/technetwork/java/index.html" target="_top">Java</a>

            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>

                  </p></li><li class="listitem"><p>Das Dokumentations-System Dobudish für

            <span class="productname">DocBook</span>™ 4.5, eine Zusammenstellung

            diverser Stylesheets und Grafiken zur Konvertierung von

            <span class="productname">DocBook</span>™ XML in andere Formate. Das

            Paket, das benötigt wird, ist zum Zeitpunkt der

            Dokumentationserstellung

            <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>

            bereitsteht.</p></li></ul></div><p>Apache Ant sowie ein dazu passendes Java Runtime Environment

        sind auf allen gängigen Plattformen verfügbar. Beispiel für

        Debian/Ubuntu:</p><pre class="programlisting">apt-get install ant openjdk-7-jre</pre><p>Nach dem Download von Dobudish muss Dobudish im Unterverzeichnis

        <code class="filename">doc/build</code> entpackt werden. Beispiel unter der

        Annahme, das <span class="productname">Dobudish</span>™ in

        <code class="filename">$HOME/Downloads</code> heruntergeladen wurde:</p><pre class="programlisting">cd doc/build

unzip $HOME/Downloads/dobudish-nojre-1.1.4.zip</pre></div><div class="sect2" title="4.7.3. PDFs und HTML-Seiten erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.build"></a>4.7.3. PDFs und HTML-Seiten erstellen</h3></div></div></div><p>Die eigentliche Konvertierung erfolgt nach Installation der

        benötigten Software mit einem einfachen Aufruf direkt aus dem

        kivitendo-Installationsverzeichnis heraus:</p><pre class="programlisting">./scripts/build_doc.sh</pre></div><div class="sect2" title="4.7.4. Einchecken in das Git-Repository"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.repository"></a>4.7.4. Einchecken in das Git-Repository</h3></div></div></div><p>Sowohl die XML-Datei als auch die erzeugten PDF- und

        HTML-Dateien sind Bestandteil des Git-Repositories. Daraus folgt, dass

        nach Änderungen am XML die PDF- und HTML-Dokumente ebenfalls gebaut

        und alles zusammen in einem Commit eingecheckt werden sollten.</p><p>Die "<code class="filename">dobudish</code>"-Verzeichnisse bzw.

        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="ch04s06.html">Zurück</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right">&nbsp;</td></tr><tr><td width="40%" align="left" valign="top">4.6. Stil-Richtlinien&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top">&nbsp;</td></tr></table></div></body></html>

        Formularen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch03s03.html">3.3. Excel-Vorlagen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch03s03.html#excel-templates.summary">3.3.1. Zusammenfassung</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.usage">3.3.2. Bedienung</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.syntax">3.3.3. Variablensyntax</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.limitations">3.3.4. Einschränkungen</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="ch04.html">4. Entwicklerdokumentation</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch04.html#devel.globals">4.1. Globale Variablen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04.html#d0e4348">4.1.1. Wie sehen globale Variablen in Perl aus?</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4449">4.1.2. Warum sind globale Variablen ein Problem?</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4482">4.1.3. Kanonische globale Variablen</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4862">4.1.4. Ehemalige globale Variablen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s02.html">4.2. Entwicklung unter FastCGI</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.general">4.2.1. Allgemeines</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.exiting">4.2.2. Programmende und Ausnahmen</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.globals">4.2.3. Globale Variablen</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.performance">4.2.4. Performance und Statistiken</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.known-issues">4.2.5. Bekannte Probleme</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s03.html">4.3. SQL-Upgradedateien</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.introduction">4.3.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.format">4.3.2. Format der Kontrollinformationen</a></span></dt><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.dbupgrade-tool">4.3.3. Hilfsscript dbupgrade2_tool.pl</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s04.html">4.4. Translations and languages</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s04.html#translations-languages.introduction">4.4.1. Introduction</a></span></dt><dt><span class="sect2"><a href="ch04s04.html#translations-languages.file-structure">4.4.2. File structure</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s05.html">4.5. Die kivitendo-Test-Suite</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.intro">4.5.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.prerequisites">4.5.2. Voraussetzungen</a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.execution">4.5.3. 

          Existierende Tests ausführen

        </a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.meaning_of_scripts">4.5.4. 

          Bedeutung der verschiedenen Test-Scripte

        </a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.create_new">4.5.5. 

          Neue Test-Scripte erstellen

        </a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s06.html">4.6. Stil-Richtlinien</a></span></dt><dt><span class="sect1"><a href="ch04s07.html">4.7. Dokumentation erstellen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.introduction">4.7.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.required-software">4.7.2. Benötigte Software</a></span></dt><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.build">4.7.3. PDFs und HTML-Seiten erstellen</a></span></dt><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.repository">4.7.4. Einchecken in das Git-Repository</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left">&nbsp;</td><td width="20%" align="center">&nbsp;</td><td width="40%" align="right">&nbsp;<a accesskey="n" href="ch01.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">&nbsp;</td><td width="20%" align="center">&nbsp;</td><td width="40%" align="right" valign="top">&nbsp;Kapitel 1. Aktuelle Hinweise</td></tr></table></div></body></html>