Use an indent of 4 spaces, with no tabs. If you use Emacs to edit PEAR
code, you should set indent-tabs-mode to nil. Here is an example mode
hook that will set up Emacs according to these guidelines (you will
need to ensure that it is called when you are editing php files):
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))
|
Here are vim rules for the same thing:
Hier sind die vim rules für das gleiche Problem:
set expandtab set shiftwidth=4 set tabstop=4 |
These include if, for, while, switch, etc. Here is an example if
statement, since it is the most complicated of them:
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;
}
|
Control statements should have one space between the control keyword
and opening parenthesis, to distinguish them from function calls.
Kontrollstrukturen sollten ein Leerzeichen zwischen dem Schlüsselwort und der öffnenden Klammer haben, um sie von Funktionsaufrufen besser zu unterscheiden.
You are strongly encouraged to always use curly braces even in
situations where they are technically optional. Having them
increases readability and decreases the likelihood of logic errors
being introduced when new lines are added.
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.
For switch statements:
Für switch-Anweisungen:
switch (Bedingung) {
case 1:
Anweisung1;
break;
case 2:
Anweisung2;
break;
default:
Default-Anweisung;
break;
}
|
Functions should be called with no spaces between the function
name, the opening parenthesis, and the first parameter; spaces
between commas and each parameter, and no space between the last
parameter, the closing parenthesis, and the semicolon. Here's an
example:
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); |
As displayed above, there should be one space on either side of an
equals sign used to assign the return value of a function to a
variable. In the case of a block of related assignments, more space
may be inserted to promote readability:
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); |
Function declaractions follow the "one true brace" convention:
Funktionsdeklarationen folgen der "eine entsprechnde Klammer" Konvention:
function fooFunction($arg1, $arg2 = '')
{
if (Bedingung) {
Anweisung;
}
return $val;
}
|
Arguments with default values go at the end of the argument list.
Always attempt to return a meaningful value from a function if one
is appropriate. Here is a slightly longer example:
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;
}
|
Inline documentation for classes should follow the PHPDoc
convention, similar to Javadoc. More information about PHPDoc can
be found here: http://www.phpdoc.de/
Inline-Dokumentation für Klassen sollten entsprechend der PHPDoc Konvention erfolgen (ähnlich Javadoc). Mehr Information über PHPDoc finden Sie hier: http://www.phpdoc.de/
Non-documentation comments are strongly encouraged. A general rule of
thumb is that if you look at a section of code and think "Wow, I don't
want to try and describe that", you need to comment it before you
forget how it works.
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.
C style comments (/* */) and standard C++ comments (// ) are both
fine. Use of perl/shell style comments (# ) is discouraged.
Kommentare im Stil von C (/* */) und C++ (// ) sind zu verwenden, während Kommentare im Stile von perl/shell (#) zu vermeiden sind.
Anywhere you are unconditionally including a class file, use
require_once(). Anywhere you are conditionally
including a class file (for example, factory methods), use
include_once(). Either of these will ensure
that class files are included only once. They share the same file
list, so you don't need to worry about mixing them - a file
included with require_once() will not be
included again by include_once().
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.
Note: include_once() and require_once() are statements, not functions. You don't need parentheses around the filename to be included.
Anmerkung: include_once() und require_once() sind Statements, keine Funktionen. Sie benötigen keine Klammern um den Dateinamen, um die Datei einzufügen.
Always use <?php ?> to
delimit PHP code, not the <? ?> shorthand.
This is required for PEAR compliance and is also the most portable
way to include PHP code on differing operating systems and setups.
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.
All source code files in the core PEAR distribution should contain
the following comment block as the header:
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@php.net so we can mail you a copy immediately. | // +----------------------------------------------------------------------+ // | Authors: Original Author <author@example.com> | // | Ihr Name <you@example.com> | // +----------------------------------------------------------------------+ // // $Id$ |
There's no hard rule to determine when a new code contributer
should be added to the list of authors for a given source file.
In general, their changes should fall into the "substantial"
category (meaning somewhere around 10% to 20% of code changes).
Exceptions could be made for rewriting functions or contributing
new logic.
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.
Simple code reorganization or bug fixes would not justify the
addition of a new individual to the list of authors.
Einfache Reorganisation von Code oder das beheben von Bugs
würde ein Hinzufügen einer neuen Person in die Liste der Autoren nicht rechtfertigen.
Files not in the core PEAR repository should have a similar block
stating the copyright, the license, and the authors. All files
should include the modeline comments to encourage consistency.
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.
Include the $Id$ CVS vendor tag in each file. As each file
is edited, add this tag if it's not yet present (or replace
existing forms such as "Last Modified:", etc.).
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: We have a custom $Horde tag in Horde cvs to track our versions seperately; we could do the same and make a $PEAR tag, that would remain even if PEAR files were put into another source control system, etc...]
Anmerkung: 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.
Use "example.com" for all example URLs, per RFC 2606.
Verwenden Sie "example.com"
lt. RFC 2606 für alle Beispiel URLs.
Constants should always be uppercase, with underscores to seperate
words. Prefix constant names with the name of the class/package
they are used in. For example, the constants used by the
DB:: package all begin with
"DB_".
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_".