mk Fri May 18 14:08:07 2001 EDT
Added files:
/phpdoc/de/pear standards.xml
Modified files:
/phpdoc/de Translators
/phpdoc/de/pear about.xml
Log:
PEAR Stuff updated, committed Files by Thomas Sch�fbeck
Index: phpdoc/de/Translators
diff -u phpdoc/de/Translators:1.164 phpdoc/de/Translators:1.165
--- phpdoc/de/Translators:1.164 Fri May 18 13:13:06 2001
+++ phpdoc/de/Translators Fri May 18 14:08:07 2001
@@ -147,7 +147,8 @@
variables.xml Thomas Schuermann fertig
-------- pear --------------------------------------------------------------
about.xml Mark Kronsbein fertig
+ Thomas Sch�fbeck
pear.xml
-standards.xml
+standards.xml Thomas Sch�fbeck fertig
----------------------------------------------------------------------------
preface.xml Egon Schmid fertig
Index: phpdoc/de/pear/about.xml
diff -u phpdoc/de/pear/about.xml:1.1 phpdoc/de/pear/about.xml:1.2
--- phpdoc/de/pear/about.xml:1.1 Wed May 16 16:45:01 2001
+++ phpdoc/de/pear/about.xml Fri May 18 14:08:07 2001
@@ -2,39 +2,41 @@
<title>�ber PEAR</title>
<simpara>
PEAR ist <ulink url="&url.malinimg;">Malin Bakken</ulink> gewidmet,
- geboren am 1999-11-21 (der erste PEAR Code wurde zwei Stunden vor
- ihrer Geburt geschrieben).
+ die am 21.11.1999 geboren wurde (der erste PEAR Code wurde gerade
+ einmal zwei Stunden vor ihrer Geburt geschrieben).
</simpara>
<sect1 id="pear-whatis">
- <title>Was ist PEAR?</title>
+ <title>Whas ist PEAR?</title>
<simpara>
- PEAR ist eine Code Sammlung f�r PHP Erweiterungen und PHP Code-Bibliotheken
- angeregt durch TeX's CTAN und Perl's CPAN.
+ PEAR ist ein Code-Archiv f�r PHP Erweiterungen und PHP
+ Bibliotheken, inspiriert von TeX's CTAN und Perl's CPAN.
</simpara>
<para>
- Das Ziel von PEAR ist:
+ Der Zweck von PEAR ist:
<itemizedlist>
<listitem>
<simpara>
- Autoren einheitliche Mittel bereitzustellen, um andere
- Entwicklern an ihrem Code teilhaben zu lassen
+ eine einheitliche M�glichkeit f�r Autoren von Bibliotheken zu
+ bieten, andere Entwickler an ihrem Code mitarbeiten, bzw. ihren
+ Code mitverwenden zu lassen
</simpara>
</listitem>
<listitem>
<simpara>
- der PHP Community eine Infrastruktur zur Verbreitung von Code zu bieten
+ der PHP-Gemeinde eine Infrastruktur zu geben, um sich die gleiche
+ Code-Basis teilen zu k�nnen
</simpara>
</listitem>
<listitem>
<simpara>
- Standards festzulegen, welche Entwicklern helfen, portierbaren und
- benutzbaren Code zu schreiben
+ Standards zu definieren, um die Entwickler beim Schreiben von
+ portablem und wiederverwendbarem Code zu unterst�tzen
</simpara>
</listitem>
<listitem>
<simpara>
- Werkzeuge f�r Verwaltung und Verbreitung von Code bereitzustellen
+ Werkzeuge zur Wartung und Verteilung der Codes anzubieten
</simpara>
</listitem>
</itemizedlist>
Index: phpdoc/de/pear/standards.xml
+++ phpdoc/de/pear/standards.xml
<chapter id="pear.standards">
<title>PEAR Codierstandards</title>
<sect1 id="pear.standards.indenting">
<title>Einr�cken</title>
<para>
Benutzen Sie Einr�ckungen von 4 Zeichen, ohne Tabulatoren. Wenn Sie
Emacs zum editieren von PEAR Code verwenden, sollten Sie den
indent-tabs-mode auf nil setzen. Hier ist ein Beispiel f�r einen
mode-hook, welcher Emacs entsprechend dieser Richtlinien konfiguriert
(versichern Sie sich, da� der mode-hook auch aufgerufen wird, wenn Sie
PHP Dateien editieren):
<programlisting role="elisp">
(defun php-mode-hook ()
(setq tab-width 4
c-basic-offset 4
c-hanging-comment-ender-p nil
indent-tabs-mode nil))
</programlisting>
</para>
<para>Hier sind die vim rules f�r das gleiche Problem:
<programlisting role="vim">
set expandtab
set shiftwidth=4
set tabstop=4
</programlisting>
</para>
</sect1>
<sect1 id="pear.standards.control">
<title>Kontrollstrukturen</title>
<para>
Diese beinhalten if, for, while, switch, etc. Hier ein Beispiel f�r
eine if Anweisung, nachdem es die komplizierteste von ihnen ist:
<programlisting role="php">
if ((Bedingung1) || (Bedingung2)) {
Anweisung1;
} elseif ((Bedingung3) && (Bedingung4)) {
Anweisung2;
} else {
Default-Anweisung;
}
</programlisting>
</para>
<simpara>
Kontrollstrukturen sollten ein Leerzeichen zwischen dem Schl�sselwort
und der �ffnenden Klammer haben, um sie von Funktionsaufrufenbesser zu
unterscheiden.
</simpara>
<simpara>
Sie sollten immer geschweifte Klammern benutzen auch wenn sie in
manchen Situationen rein technisch nur optional anzuwenden sind. Sie
zu verwenden erh�ht nicht nur die Lesbarkeit und vermindert daher die
Wahrscheinlichkeit von logischen Fehlern, wenn neue Zeilen hinzugef�gt
werden.
</simpara>
<para>
F�r switch-Anweisungen:
<programlisting role="php">
switch (Bedingung) {
case 1:
Anweisung1;
break;
case 2:
Anweisung2;
break;
default:
Default-Anweisung;
break;
}
</programlisting>
</para>
</sect1>
<sect1 id="pear.standards.funcalls">
<title>Funktionsaufrufe</title>
<para>
Funktionsaufrufe sollten zwischen dem Funktionsnamen, der �ffnenden
Klammer, und dem ersten Parameter, sowie zwischen dem letzten Parameter
und der schlie�enden Klammer keine Leerzeichen enthalten. Die einzelnen
Parameter sollten zwischen den Beistrichen und dem n�chsten Parameter
durch Leerzeichen getrennt werden. Hier ein Beispiel:
<programlisting role="php">
$var = foo($bar, $baz, $quux);
</programlisting>
</para>
<para>
Wie oben gezeigt, sollte das zur Zuweisung des R�ckgabewertes einer
Funktion an eine Variable verwendete Gleichheitszeichen auf jeder Seite
von einem Leerzeichen umgeben sein. Im Falle eines Blocks von
Zuweisungen k�nnen mehrere Leerzeichen eingef�gt werden, um die
Lesbarkeit zu erh�hen:
<programlisting role="php">
$short = foo($bar);
$long_variable = foo($baz);
</programlisting>
</para>
</sect1>
<sect1 id="pear.standards.funcdef">
<title>Funktionsdefinitionen</title>
<para>
Funktionsdeklarationen folgen der "eine entsprechnde Klammer" Konvention:
<programlisting role="php">
function fooFunction($arg1, $arg2 = '')
{
if (Bedingung) {
Anweisung;
}
return $val;
}
</programlisting>
</para>
<para>
Argumente mit Default-Werten werden am Ende der Argumentenliste
aufgef�hrt. Versuchen Sie immer einen bedeutungsvollen Wert von einer
Funktion zur�ckzugeben, wenn ein R�ckgabewert angebracht ist. Hier ein
etwas l�ngeres Beispiel:
<programlisting role="php">
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}
if (!$dsninfo || !$dsninfo['phptype']) {
return $this->raiseError();
}
return true;
}
</programlisting>
</para>
</sect1>
<sect1 id="pear.standards.comments">
<title>Kommentare</title>
<para>
Inline-Dokumentation f�r Klassen sollten entsprechend der PHPDoc
Konvention erfolgen (�hnlich Javadoc). Mehr Information �ber PHPDoc
finden Sie hier: <ulink url="&url.phpdoc;">&url.phpdoc;</ulink>
</para>
<para>
Weitere Kommentare, welche nicht der Klassendokumentation dienen, werden
nachdr�cklich empfohlen. Eine generelle Faustregel ist: Wenn Sie auf ein
St�ck Code blicken und denken "Wow, ich m�chte das nicht versuchen und
beschreiben", da� Sie es auf jeden Fall kommentieren sollten, bevor Sie
vergessen, wie es funktioniert.
</para>
<para>
Kommentare im Stil von C (/* */) und C++ (// ) sind zu verwenden,
w�hrend Kommentare im Stile von perl/shell (#) zu vermeiden sind.
</para>
</sect1>
<sect1 id="pear.standards.including">
<title>Einf�gen von Code</title>
<para>
Verwenden Sie �berall dort, wo Sie bedingungslos eine Klassendatei
einf�gen <function>require_once</function>. Wenn Sie eine Klassendatei
bedingt einf�gen wollen (z.B. Fabrikmethoden) verwenden Sie
<function>include_once</function>. Beide Anweisungen stellen sicher, da�
die einzuf�gende Datei nur einmal eingef�gt wird. Sie benutzen die selbe
Dateiliste, weshalb Sie sich keine Sorgen �ber deren gleichzeitige
Benutzung machen brauchen - alle mittels <function>require_once</function>
eingef�gten Dateien werden mittels <function>include_once</function>
nicht noch einmal eingef�gt.
<note>
<simpara>
<function>include_once</function> und
<function>require_once</function> sind Statements, keine Funktionen.
Sie <emphasis>ben�tigen</emphasis> keine Klammern um den Dateinamen,
um die Datei einzuf�gen.
</simpara>
</note>
</para>
</sect1>
<sect1 id="pear.standards.tags">
<title>PHP Code Tags</title>
<para>
Benutzen Sie <emphasis>immer</emphasis> <literal><?php ?></literal>
um den PHP Code zu begrenzen, und nicht die Kurzform
<literal><? ?></literal>. Dies ist zur PEAR Konformit�t erforderlich
und ist auch der portabelste Weg, PHP Code auf verschiedenen
Betriebssystemen bzw. Setups einzuf�gen.
</para>
</sect1>
<sect1 id="pear.standards.header">
<title>Kommentare im Dateikopf</title>
<para>
Alle Source Code-Dateien in der PEAR Kerndistribution sollten den
folgenden Kommentarblock am Anfang der Datei enthalten:
<programlisting role="php">
/* vim: set expandtab tabstop=4 shiftwidth=4: */
// +----------------------------------------------------------------------+
// | PHP version 4.0 |
// +----------------------------------------------------------------------+
// | Copyright (c) 1997, 1998, 1999, 2000, 2001 The PHP Group |
// +----------------------------------------------------------------------+
// | This source file is subject to version 2.0 of the PHP license, |
// | that is bundled with this package in the file LICENSE, and is |
// | available at through the world-wide-web at |
// | http://www.php.net/license/2_02.txt. |
// | If you did not receive a copy of the PHP license and are unable to |
// | obtain it through the world-wide-web, please send a note to |
// | [EMAIL PROTECTED] so we can mail you a copy immediately. |
// +----------------------------------------------------------------------+
// | Authors: Original Author <[EMAIL PROTECTED]> |
// | Ihr Name <[EMAIL PROTECTED]> |
// +----------------------------------------------------------------------+
//
// $Id$
</programlisting>
</para>
<para>
Es gibt keine festen Regeln, wann ein neuer Code Autor f�r seine
Beitr�ge der Liste von Autoren hinzugef�gt werden sollte. Generell
sollten dessen �nderungen in die Kategorie "Erheblich" fallen (d.h.
sie sollten irgendwo bei 10 bis 20 Prozent der Code�nderungen liegen).
Ausnahmen k�nnten f�r das Umschreiben von Funktionen oder das Beisteuern
einer neuen Logik gemacht werden.
</para>
<para>
Einfache Reorganisation von Code oder das beheben von Bugs w�rde ein
Hinzuf�gen einer neuen Person in die Liste der Autoren nicht rechtfertigen.
</para>
<para>
Dateien au�erhalb des PEAR Kernarchivs sollten einen �hnlichen Block mit
Copyright, Lizenz, und den Autoren aufweisen. Alle Dateien sollten
au�erdem die modeline Kommentare enthalten, um die Konsistenz zu f�rdern.
</para>
</sect1>
<sect1 id="pear.standards.cvstags">
<title>CVS Tags</title>
<para>
F�gen Sie den $Id$ CVS Tag in jede Datei ein. Wenn Sie
eine Datei editieren und dieser Tag noch nicht vorhanden ist, f�gen Sie
ihn bitte hinzu (oder ersetzen Sie bereits vorhandene Formen wie "Last
Modified:", etc.).
<note>
<simpara>
Wir haben einen speziellen $Horde Tag in Horde CVS, um unsere
Versionen getrennt zu verfolgen; wir k�nnten das gleiche tun und
einen $PEAR Tag einf�hren, welcher auch bleiben w�rde, wenn die
PEAR Dateien einmal von einem anderen Source-Kontrollsystem
verwaltet werden, etc.
</simpara>
</note>
</para>
</sect1>
<sect1 id="pear.standards.exampleurls">
<title>Beispiel URLs</title>
<para>
Verwenden Sie "example.com" lt. RFC 2606 f�r alle Beispiel URLs.
</para>
</sect1>
<sect1 id="pear.standards.constants">
<title>Konstanten benennen</title>
<para>
Konstanten sollten immer in Gro�buchstaben benannt werden, und die
Worttrennung sollte mit Unterstrichen erfolgen. Geben Sie als Pr�fix
zum Konstantennamen den Namen der Klasse bzw. des Paketes an, in
welcher die Konstante benutzt wird. Zum Beispiel beginnen alle
Konstanten, welche von dem <literal>DB::</literal> - Paket benutzt
werden, mit "<literal>DB_</literal>".
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
