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 @@ Über PEAR PEAR ist Malin Bakken 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). - Was ist PEAR? + Whas ist PEAR? - 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. - Das Ziel von PEAR ist: + Der Zweck von PEAR ist: - 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 - 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 - 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 - Werkzeuge für Verwaltung und Verbreitung von Code bereitzustellen + Werkzeuge zur Wartung und Verteilung der Codes anzubieten Index: phpdoc/de/pear/standards.xml +++ phpdoc/de/pear/standards.xml PEAR Codierstandards Einrücken 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): (defun php-mode-hook () (setq tab-width 4 c-basic-offset 4 c-hanging-comment-ender-p nil indent-tabs-mode nil)) Hier sind die vim rules für das gleiche Problem: set expandtab set shiftwidth=4 set tabstop=4 Kontrollstrukturen Diese beinhalten if, for, while, switch, etc. Hier ein Beispiel für eine if Anweisung, nachdem es die komplizierteste von ihnen ist: if ((Bedingung1) || (Bedingung2)) { Anweisung1; } elseif ((Bedingung3) && (Bedingung4)) { Anweisung2; } else { Default-Anweisung; } Kontrollstrukturen sollten ein Leerzeichen zwischen dem Schlüsselwort und der öffnenden Klammer haben, um sie von Funktionsaufrufenbesser zu unterscheiden. 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. Für switch-Anweisungen: switch (Bedingung) { case 1: Anweisung1; break; case 2: Anweisung2; break; default: Default-Anweisung; break; } Funktionsaufrufe 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: $var = foo($bar, $baz, $quux); 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: $short = foo($bar); $long_variable = foo($baz); Funktionsdefinitionen Funktionsdeklarationen folgen der "eine entsprechnde Klammer" Konvention: function fooFunction($arg1, $arg2 = '') { if (Bedingung) { Anweisung; } return $val; } 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: 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; } Kommentare Inline-Dokumentation für Klassen sollten entsprechend der PHPDoc Konvention erfolgen (ähnlich Javadoc). Mehr Information über PHPDoc finden Sie hier: &url.phpdoc; 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. Kommentare im Stil von C (/* */) und C++ (// ) sind zu verwenden, während Kommentare im Stile von perl/shell (#) zu vermeiden sind. Einfügen von Code Verwenden Sie überall dort, wo Sie bedingungslos eine Klassendatei einfügen require_once. Wenn Sie eine Klassendatei bedingt einfügen wollen (z.B. Fabrikmethoden) verwenden Sie include_once. 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 require_once eingefügten Dateien werden mittels include_once nicht noch einmal eingefügt. include_once und require_once sind Statements, keine Funktionen. Sie benötigen keine Klammern um den Dateinamen, um die Datei einzufügen. PHP Code Tags Benutzen Sie immer <?php ?> um den PHP Code zu begrenzen, und nicht die Kurzform <? ?>. Dies ist zur PEAR Konformität erforderlich und ist auch der portabelste Weg, PHP Code auf verschiedenen Betriebssystemen bzw. Setups einzufügen. Kommentare im Dateikopf Alle Source Code-Dateien in der PEAR Kerndistribution sollten den folgenden Kommentarblock am Anfang der Datei enthalten: /* 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 | // | license <email protected> so we can mail you a copy immediately. | // +----------------------------------------------------------------------+ // | Authors: Original Author <author <email protected>> | // | Ihr Name <you <email protected>> | // +----------------------------------------------------------------------+ // // $Id$ 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. Einfache Reorganisation von Code oder das beheben von Bugs würde ein Hinzufügen einer neuen Person in die Liste der Autoren nicht rechtfertigen. 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. CVS Tags 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.). 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. Beispiel URLs Verwenden Sie "example.com" lt. RFC 2606 für alle Beispiel URLs. Konstanten benennen 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 DB:: - Paket benutzt werden, mit "DB_".