Wenn ein String ein Literal ist (er also keine Variablenvertreter enthält), sollte immer das Apostroph oder "einzelne Anführungszeichen" verwendet werden, um den String abzugrenzen:

Wenn ein literaler String selbst Apostrophe enthält, ist es gestattet den String mit Anführungszeichen oder "doppelten Anführungszeichen" abzugrenzen. Das ist speziell für SQL Anweisungen nützlich:

Diese Syntax ist zu bevorzugen, im Gegensatz zum Entwerten des Apostrophs, da sie viel einfacher lesbar ist.

Variablensubstitution ist gestattet bei Verwendung einer der Formen:

Aus Gründen der Konstistenz ist folgende Form nicht gestattet:

Strings müssen verbunden werden, indem man den "." Operator verwendet. Ein Leerzeichen muss immer vor und nach dem "." Operator hinzugefügt werden, um die Lesbarkeit zu erhöhen:

Wenn Strings mit dem "." Operator verbunden werden, ist es empfohlen, die Anweisung in mehrere Zeilen umzubrechen, um die Lesbarkeit zu erhöhen. In diesen Fällen sollte jede folgende Zeile mit Leerraum aufgefüllt werden so das der "." Operator genau unterhalb des "=" Operators ist:

Negative Zahlen sind in Indizes nicht gestattet.

Ein indiziertes Array kann mit irgendeiner nicht-negativen Zahl beginnen, trotzdem sind alle BasisIndices außer 0 nicht erlaubt.

Wenn indizierte Arrays mit der Array -Funktion deklariert werden, muß ein folgendes Leerzeichen nach jeder Kommabegrenzung hinzugefügt werden, um die Lesbarkeit zu erhöhen:

Es ist bei Verwendung des "array" Konstrukts gestattet, mehrzeilige indizierte Arrays zu definieren. In diesem Fall, muss jede folgende Zeile mit Leerzeichen aufgefüllt werden, so dass der Beginn jeder Zeile ausgerichtet ist:

Alternativ kann das beginnende Array-Element in der folgenden Zeile beginnen. Wenn das so ist, sollte es um ein Einrückungslevel tiefer stehen als die Zeile, welche die Array-Deklaration enthält und alle folgenden Zeilen sollten die gleiche Einrückung haben; der schließende Teil sollte in einer eigenen Zeile stehen und das gleiche Einrückungslevel haben wie die Zeile, welche die Array-Deklaration enthält:

Wenn die letztere Deklaration verwendet wird, empfehlen wir ein endendes Komma für das letzte Element im Array zu verwenden; das minimiert das Problem beim Hinzufügen von neuen Elements mit zusätzlichen Zeilen und hilft sicherzustellen, dass durch ein fehlendes Komma keine Parsing-Fehler auftreten.

Wenn assoziative Arrays mit dem Array -Konstrukt deklariert werden, ist das Umbrechen der Anweisung in mehrere Zeilen gestattet. In diesem Fall muss jede folgende Zeile mit Leerraum aufgefüllt werden, so dass sowohl der Schlüssel und der Wert untereinander stehen:

Alternativ kann das beginnende Array-Element in der folgenden Zeile beginnen. Wenn das so ist, sollte es um ein Einrückungslevel tiefer stehen als die Zeile, welche die Array-Deklaration enthält und alle folgenden Zeilen sollten die gleiche Einrückung haben; der schließende Teil sollte in einer eigenen Zeile stehen und das gleiche Einrückungslevel haben wie die Zeile, welche die Array-Deklaration enthält. Wegen der Lesbarkeit sollten die verschiedenen "=>" Operatoren so eingerückt werden, dass sie untereinander stehen.

Wenn die letztere Deklaration verwendet wird, empfehlen wir ein endendes Komma für das letzte Element im Array zu verwenden; das minimiert das Problem beim Hinzufügen von neuen Elements bei zusätzlichen Zeilen und hilft sicherzustellen, dass durch ein fehlendes Komma keine Parsing-Fehler auftreten.

Klassen müssen entsprechend der Zend Framework Namenskonvention benannt werden.

Die Klammer sollte immer in der Zeile unter dem Klassennamen geschrieben werden.

Jede Klasse muss einen Dokumentationsblock haben der dem PHPDocumentor-Standard entspricht.

Jeder Code in der Klasse muss mit vier Leerzeichen eingerückt sein.

Nur eine Klasse ist in jeder PHP-Datei gestattet.

Das Platzieren von zusätzlichem Code in Klassendateien ist gestattet, aber es wird davon abgeraten. In solchen Dateien müssen zwei leere Zeilen die Klasse von jedem zusätzlichen PHP-Code in der Datei trennen.

Das folgende ist ein Beispiel einer akzeptierbaren Klassendeklaration:

Klassen, die andere Klassen erweitern oder welche Interfaces implementieren, sollen ihre Abhängigkeit auf der gleichen Zeile deklarieren, wenn das möglich ist.

Wenn als Ergebnis so einer Deklaration, die Länge der Zeile die Maximale Zeilenlänge überschreitet, ist die Zeile vor dem "extends" und oder "implements" Schlüsselwort umzubrechen und diese Zeilen um ein Einrückungslevel einzurücken.

Wenn die Klasse mehrere Interfaces implementiert und die Deklaration die maximale Zeilenlänge übersteigt, ist nach jedem Komma umzubrechen und sind die Interfaces zu separieren und die Namen der Interfaces so einzurücken, dass sie untereinander stehen.

Klassenvariablen müssen entsprechend den Variablen-Benennungs-Konventionen des Zend Frameworks benannt werden.

Jede Variable, die in der Klasse deklariert wird, muss am Beginn der Klasse vor der Deklaration von allen Methoden aufgelistet werden.

Das var Konstrukt ist nicht gestattet. Klassenvariablen definieren Ihre Sichtbarkeit durch die Verwendung des private, protected oder public Modifikatoren. Das Gestatten von direktem Zugriff auf Klassenvariablen durch deren Deklaration als public ist gestattet, aber es wird davon abgeraten, da hierfür Zugriffsmethoden verwendet werden sollten (set & get).

Funktionen müssen nach der Funktions-Namenskonvention des Zend Frameworks benannt werden.

Methoden innerhalb von Klassen müssen immer ihre Sichtbarkeit durch Verwendung einer der private, protected, oder public Modifikatoren definieren.

Wie bei Klassen, sollte die Klammer immer in der Zeile unterhalb des Funktionsnamens geschrieben werden. Leerzeichen zwischen dem Funktionsnamen und der öffnenden Klammer für die Argumente sind nicht erlaubt.

Von Funktionen im globalen Raum wird komplett abgeraten.

Das folgende ist ein Beispiel einer akzeptierbaren Funktionsdeklaration in einer Klasse:

In den Fällen wo die Liste der Argumente die maximale Zeilenlänge überschreitet, sollten Zeilenumbrüche eingeführt werden. Zusätzliche Argumente der Funktion oder Methode müssen durch einen zusätzlichen Einrückungslevel nach der Funktion oder Methodendeklaration eingerückt werden. Ein Zeilenumbruch sollte dann vor dem schließenden Argument stattfinden, welcher in der gleichen Zeile platziert werden sollte wie die öffnende Klammer der Funktion oder Methode mit einem einzelnen Leerzeichen das die zwei trennt, und mit dem gleichen Einrückungslevel wie die Deklaration der Funktion oder Methode. Das folgende ist ein Beispiel so einer Situation:

Note: Notiz: Die Übergabe per Referenz ist der einzige erlaubt Mechanismus für die Übergabe von Parametern in der Deklaration einer Funktion:

Der Aufruf durch Referenz ist nicht gestattet.

Der Rückgabewert darf nicht in Klammern stehen. Das kann die Lesbarkeit behindern und zusätzlich den Code unterbrechen, wenn eine Methode später auf Rückgabe durch Referenz geändert wird.

Funktionsargumente sollten durch ein einzelnes trennendes Leerzeichen nach dem Komma-Trennzeichen getrennt werden. Das folgende ist ein Beispiel für einen akzeptierbaren Aufruf einer Funktion, die drei Argumente benötigt:

Übergabe von Referenzen zur Laufzeit ist strengstens verboten. Siehe die Sektion für Funktionsdeklarationen für den richtigen Weg um Funktionsargumente per Referenz zu übergeben.

Durch die Übergabe von Arrays als Argument für eine Funktion, kann der Funktionsaufruf den "array" Hinweis enthalten und kann in mehrere Zeilen geteilt werden, um die Lesbarkeit zu erhöhen. In solchen Fällen sind die normalen Richtlinien für das Schreiben von Arrays trotzdem noch anzuwenden:

Kontrollanweisungen, die auf den if und elseif Konstrukten beruhen müssen ein einzelnes Leerzeichen vor der öffnenden Klammer der bedingten Anweisung und ein einzelnes Leerzeichen nach der schließenden Klammer haben.

Innerhalb der bedingten Anweisungen zwischen den Klammern, müssen die Operationen, für die Lesbarkeit, durch Leerzeichen getrennt werden. Innere Klammern sind zu befürworten um die logische Gruppierung für größeren bedingte Anweisungen zu erhöhen.

Die öffnende Klammer wird in der selben Zeile geschrieben wie die Bedingungsanweisung. Die schließende Klammer wird immer in einer eigenen Zeile geschrieben. Jeder Inhalt innerhalb der Klammer muß durch Verwendung von vier Leerzeichen eingerückt werden.

Wenn die Kontrollanweisung die Ursache für eine Überschreitung der maximalen Zeilenlänge ist, und sie mehrere Anweisungen hat, kann die Kontrollanweisung in mehrere Zeilen gebrochen werden. In solchen Fällen, ist die Zeile vor dem logischen Operator zu brechen und die Zeile so einzurücken das sie unter dem ersten Zeichen der Kontrollanweisung steht. Der schließende Teil der Kontrollanweisung ist mit der öffnenden Klammer in einer eigenen Zeile zu platzieren, wobei ein einzelnes Leerzeichen die zwei trennen muß, und der Einrückungslevel identisch mit der öffenden Kontrollanweisung sein ist.

Die Einrückung des späteren Deklarationsformats dient der Vorbeugung von Problemen beim Hinzufügen oder Entfernen von Klauseln von der Kontrollanweisung bei späteren Revisionen.

Für "if" Anweisungen die "elseif" oder "else" beinhalten, sind die Konventionen der Formatierung ähnlich dem "if" Konstrukt. Das folgende Beispiel zeigt gültige Formatierungen für "if" Anweisungen mit "else" und/oder "elseif" Konstrukten:

PHP erlaubt in einigen Fällen auch Anweisungen ohne Klammern. Dieser Coding Standard macht keine Unterscheidungen und es müssen alle "if", "elseif" oder "else" Anweisungen in Klammern geschrieben werden.

Kontrollanweisungen die mit der "switch" Anweisung geschrieben werden müssen ein einzelnes Leerzeichen vor der öffnenden Klammer der bedingten Anweisung besitzen und auch nach der schließenden Klammer.

Jeglicher Inhalt innerhalb der "switch" Anweisung muß durch Verwendung von vier Leerzeichen eingerückt sein. Der Inhalt unter jeder "case" Anweisung muß durch Verwendung von vier zusätzlichen Leerzeichen eingerückt werden.

Das default Konstrukt darf nie bei der switch Anweisung vergessen werden.

Note: Notiz: Es ist machmal nützlich eine case-Anweisung zu schreiben, die durch das nächste case fällt, indem innerhalb solcher Fälle kein break oder return angegeben wird. Um diese Fälle von Fehlern zu unterscheiden, sollte jede case-Anweisung, in der break oder return unterlassen werden, einen Kommentar enthalten, der anzeigt, dass das break gewünschtermaßen unterdrückt wurde.

Alle Dokumentationsblöcke ("DocBlock") müssen mit dem phpDocumentor-Format kompatibel sein. Die Beschreibung des phpDocumentor-Formats ist nicht Thema dieses Dokuments. Für weiterführende Informationen siehe: » http://phpdoc.org">

Alle Klassendateien müssen einen "file-level" Docblock am Beginn jeder Datei und einen "class-level" Docblock direkt oberhalb jeder Klasse enthalten. Beispiele solcher Docblocks können im folgenden gefunden werden.

Jede Datei, die PHP Code enthält, muss einen Docblock am Beginn der Datei besitzen, welcher mindestens diese phpDocumentor-Tags enthält:

Das @category Tag muß den Wert "Zend" haben.

Das @package Tag muß hinzugefügt sein, und sollte mit dem Namen der Komponente identisch sein, dessen Klasse in der Datei enthalten ist; typischerweise wird dieser zwei Segmente haben, das Präfix "Zend", und den Namen der Komponente.

Das @subpackage Tag ist optional. Wenn es angegeben wird, sollte es der Name der Subkomponente sein, ohne das Präfix der Klasse. Im obigen Beispiel ist die Annahme, dass die Klasse in der Datei entweder "Zend_Magic_Wand" ist oder den Klassennamen als Teil seines Präfixes verwendet.

Jede Klasse muss einen Docblock haben, welcher mindestens diese phpDocumentor Tags enthält:

Das @category Tag muß den Wert "Zend" haben.

Das @package Tag muß hinzugefügt sein, und sollte mit der Komponente identisch sein, der die Klasse gehört; typischerweise wird dieser zwei Segmente haben, den Präfix "Zend", und den Namen der Komponente.

Das @subpackage Tag ist optional. Wenn es angegeben wird, sollte es der Name der Subkomponente sein, ohne das Präfix der Klasse. Im obigen Beispiel ist die Annahme, dass die Klasse in der Datei entweder "Zend_Magic_Wand" ist oder den Klassennamen als Teil seines Präfixes verwendet.

Jede Funktion, auch Objektmethoden, müssen einen Docblock haben, welcher mindestens folgendes enthält:

• Eine Beschreibung der Funktion

• Alle Argumente

• Alle möglichen Rückgabewerte

Es ist nicht notwendig, das "@access" Tag zu verwenden, weil das Accesslevel bereits vom "public", "private" oder "protected" Modifikator bekannt ist, wenn die Funktion deklariert wird.

Wenn eine Funktion oder Methode eine Ausnahme werfen könnte, muß @throws für alle bekannten Exception Klassen verwendet werden: