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