Projekt

Allgemein

Profil

« Zurück | Weiter » 

Revision 42298d2c

Von Moritz Bunkus vor fast 6 Jahren hinzugefügt

  • ID 42298d2ceb5206a3d8df0a5cd9989eff5ebb843e
  • Vorgänger 60b17b30
  • Nachfolger 822f5cf7

Dokumentation: HTML & PDF gebaut

Unterschiede anzeigen:

doc/html/ch04s06.html
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 3.5.3: 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
}
<title>4.6. 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 3.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Translations and languages"><link rel="next" href="ch04s07.html" title="4.7. 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. Die kivitendo-Test-Suite</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. Die kivitendo-Test-Suite"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.testsuite"></a>4.6. Die kivitendo-Test-Suite</h2></div></div></div><div class="sect2" title="4.6.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.intro"></a>4.6.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">t/</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">t/</code>, deren Dateiname
auf <code class="literal">.t</code> endet.</p></li></ul></div></div><div class="sect2" title="4.6.2. Voraussetzungen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.prerequisites"></a>4.6.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:
<code class="literal">perl-Test-Deep</code>; openSUSE:
<code class="literal">perl-Test-Deep</code>)</p></li><li class="listitem"><p>
<code class="literal">Test::Exception</code> (Debian-Paketname:
<code class="literal">libtest-exception-perl</code>; Fedora:
<code class="literal">perl-Test-Exception</code>; openSUSE:
<code class="literal">perl-Test-Exception</code>)</p></li><li class="listitem"><p>
<code class="literal">Test::Output</code> (Debian-Paketname:
<code class="literal">libtest-output-perl</code>; Fedora:
<code class="literal">perl-Test-Output</code>; openSUSE:
<code class="literal">perl-Test-Output</code>)</p></li><li class="listitem"><p>
<code class="literal">Test::Harness</code> 3.0.0 oder höher. Dieses
Modul ist ab Perl 5.10.1 Bestandteil der Perl-Distribution und
kann für frühere Versionen aus dem <a class="ulink" href="http://www.cpan.org" target="_top">CPAN</a> bezogen werden.</p></li><li class="listitem"><p>
<code class="literal">LWP::Simple</code> aus dem Paket
<code class="literal">libwww-perl</code> (Debian-Panetname:
<code class="literal">libwww-perl</code>; Fedora:
<code class="literal">perl-libwww-perl</code>; openSUSE:
<code class="literal">perl-libwww-perl</code>)</p></li><li class="listitem"><p>
<code class="literal">URI::Find</code> (Debian-Panetname:
<code class="literal">liburi-find-perl</code>; Fedora:
<code class="literal">perl-URI-Find</code>; openSUSE:
<code class="literal">perl-URI-Find</code>)</p></li><li class="listitem"><p>
<code class="literal">Sys::CPU</code> (Debian-Panetname:
<code class="literal">libsys-cpu-perl</code>; Fedora und openSUSE: nicht
vorhanden)</p></li><li class="listitem"><p>
<code class="literal">Thread::Pool::Simple</code> (Debian-Panetname:
<code class="literal">libthread-pool-simple-perl</code>; Fedora und
openSUSE: nicht vorhanden)</p></li></ul></div><p>Weitere Voraussetzung ist, dass die Testsuite ihre eigene
Datenbank anlegen kann, um Produktivdaten nicht zu gefährden. Dazu
müssen in der Konfigurationsdatei im Abschnit
<code class="literal">testing/database</code> Datenbankverbindungsparameter
angegeben werden. Der hier angegebene Benutzer muss weiterhin das
Recht haben, Datenbanken anzulegen und zu löschen.</p><p>Der so angegebene Benutzer muss nicht zwingend über
Super-User-Rechte verfügen. Allerdings gibt es einige
Datenbank-Upgrades, die genau diese Rechte benötigen. Für den Fall
kann man in diesem Konfigurationsabschnitt einen weiteren
Benutzeraccount angeben, der dann über Super-User-Rechte verfügt, und
mit dem die betroffenen Upgrades durchgeführt werden. In der
Beispiel-Konfigurationsdatei finden Sie die benötigten
Parameter.</p></div><div class="sect2" title="4.6.3. Existierende Tests ausführen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.execution"></a>4.6.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.pl</code>.</p><p>Will man die komplette Test-Suite ausführen, so muss man einfach
nur <code class="filename">t/test.pl</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.pl</code>. Beispielsweise:</p><pre class="programlisting">t/test.pl t/form/format_amount.t t/background_job/known_jobs.t</pre></div><div class="sect2" title="4.6.4. Bedeutung der verschiedenen Test-Scripte"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.meaning_of_scripts"></a>4.6.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.6.5. Neue Test-Scripte erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.create_new"></a>4.6.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.6.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.6.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen
testen</h4></div></div></div><p>Ideen, die abgesehen von Funktionen 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.6.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.6.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 sein, 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.6.5.3. Minimales Skelett für eigene Scripte"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.minimal_example"></a>4.6.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;
if ($use_modules) {
$row-&gt;{modules} = MODULE-&gt;retrieve(
id =&gt; $row-&gt;{id},
date =&gt; $use_now ? localtime() : $row-&gt;{time},
);
}
use lib 't';
$report-&gt;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-&gt;{sum} &gt; 0) {
...
} else {
...
}
use Support::TestSetup;
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-&gt;{sum} += $form-&gt;{"row_$i"};
$form-&gt;{ $form-&gt;{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 Operator "?:", der am
besten in einer übersichtlichen Tabellenstruktur organisiert
wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form-&gt;{"row_$i"} ? $i
: $form-&gt;{oldcount} ? $form-&gt;{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-&gt;{"row_$i"} = $form-&gt;{"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>
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 </p><pre class="programlisting">Support::TestSetup::login();</pre><p>
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="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. 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.7. Stil-Richtlinien</td></tr></table></div></body></html>

Auch abrufbar als: Unified diff