Lorsqu'une chaîne est littérale (c'est-à-dire qu'elle ne contient pas de substitution de variables), l'apostrophe ou guillemet simple doit être utilisé pour démarquer la chaîne :

Lorsque qu'une chaîne littérale contient des apostrophes, il est permis de les démarquer en utilisant les guillemets doubles. Ceci est particulièrement conseillé pour les requêtes SQL :

La substitution des variables est permise en utilisant une de ces deux formes :

Pour des raisons d'uniformité, cette forme n'est pas permise :

Les chaînes peuvent êtres concaténées en utilisant l'opérateur ".". Un espace doit toujours être ajouté avant, et après cet opérateur, cela permet d'améliorer la lisibilité :

Lors de la concaténation de chaînes avec l'opérateur ".", il est permis de couper le segment en plusieurs lignes pour améliorer la lisibilité. Dans ces cas, chaque nouvelle ligne doit être remplie avec des espaces, de façon à aligner le "." sous l'opérateur "=" :

L'utilisation d'indices négatifs n'est pas permise.

Un tableau indexé peut commencer avec n'importe quel nombre positif, cependant cette méthode est déconseillée. Il est conseillé de commencer l'indexation à 0.

Lors de la déclaration de tableaux indexés avec la construction array, un espace doit être ajouté après chaque virgule délimitante, pour améliorer la lisibilité :

Il est aussi permis de déclarer des tableaux indexés sur plusieurs lignes en utilisant la construction array. Dans ce cas, chaque nouvelle ligne doit être remplie par des espaces jusqu'à ce que cette ligne s'aligne, comme il est montré dans l'exemple suivant :

Alternately, the initial array item may begin on the following line. If so, it should be padded at one indentation level greater than the line containing the array declaration, and all successive lines should have the same indentation; the closing paren should be on a line by itself at the same indentation level as the line containing the array declaration:

When using this latter declaration, we encourage using a trailing comma for the last item in the array; this minimizes the impact of adding new items on successive lines, and helps to ensure no parse errors occur due to a missing comma.

Lorsque de la déclaration de tableaux associatifs avec la construction array, il est conseillé de séparer la définition sur plusieurs lignes. Dans ce cas, chaque ligne successive doit être remplie par des espaces pour que les clés et les valeurs soient alignées :

$sampleArray = array('firstKey'  => 'firstValue',
                     'secondKey' => 'secondValue');

Alternately, the initial array item may begin on the following line. If so, it should be padded at one indentation level greater than the line containing the array declaration, and all successive lines should have the same indentation; the closing paren should be on a line by itself at the same indentation level as the line containing the array declaration. For readability, the various "=>" assignment operators should be padded such that they align.

When using this latter declaration, we encourage using a trailing comma for the last item in the array; this minimizes the impact of adding new items on successive lines, and helps to ensure no parse errors occur due to a missing comma.

Les classes doivent être nommées conformément aux conventions de nommage de Zend Framework.

L'accolade est toujours écrite dans la ligne sous le nom de la classe.

Toutes les classes doivent avoir un bloc de documentation conforme aux standards PHPDocumentor.

Tout code d'une classe doit être indenté avec 4 espaces.

Une seule classe est permise par fichier PHP.

Le placement de code additionnel dans un fichier de classe est permis, mais déconseillé. Dans ces fichiers, deux lignes vides doivent séparer la classe du code PHP additionnel.

Voici un exemple d'une déclaration de classe autorisée :

/**
 * Bloc de documentation
 */
class SampleClass
{
    // contenu de la classe
    // qui doit être indenté avec 4 espaces
}

Classes that extend other classes or which implement interfaces should declare their dependencies on the same line when possible.

If as a result of such declarations, the line length exceeds the maximum line length, break the line before the "extends" and/or "implements" keywords, and pad those lines by one indentation level.

If the class implements multiple interfaces and the declaration exceeds the maximum line length, break after each comma separating the interfaces, and indent the interface names such that they align.

Les variables membres doivent être nommées en respectant les conventions de nommage de Zend Framework.

Toute variable déclarée dans une classe doit être listée en haut de cette classe, avant toute déclaration de méthode.

La construction var n'est pas permise. Les variables membres déclarent toujours leur visibilité en utilisant la construction private, protected, ou public. L'accès direct à ces variables membres en les rendant publiques est permis mais déconseillé. Il est préférable d'utiliser des accesseurs (set/get).

Les fonctions doivent être nommées en respectant les conventions de nommage de Zend Framework.

Les fonctions internes aux classes doivent toujours déclarer leur visibilité en utilisant la construction private, protected, ou public.

Tout comme les classes, l'accolade ouvrante est toujours écrite sous le nom de la fonction. Il n'y a pas d'espace entre le nom de la fonction et les parenthèses des arguments. Il n'y a pas d'espace entre la parenthèse fermante et l'accolade.

Les fonctions globales sont fortement déconseillées.

Voici un exemple d'une déclaration permise d'une fonction de classe :

In cases where the argument list exceeds the maximum line length, you may introduce line breaks. Additional arguments to the function or method must be indented one additional level beyond the function or method declaration. A line break should then occur before the closing argument paren, which should then be placed on the same line as the opening brace of the function or method with one space separating the two, and at the same indentation level as the function or method declaration. The following is an example of one such situation:

NOTE : Le passage par référence est permis uniquement dans la déclaration de la fonction :

L'appel par référence est interdit.

La valeur de retour ne doit pas être entourée de parenthèses. Ceci peut gêner à la lecture et peut aussi casser le code si une méthode est modifiée plus tard pour retourner par référence.

Les arguments d'une fonction sont séparés par un espace après la virgule de délimitation. Voici un exemple d'un appel de fonction qui prend trois arguments :

L'appel par référence est interdit. Référez vous à la section sur la déclaration de fonctions pour la méthode correcte de passage des argument par référence.

Pour les fonctions dont les arguments peuvent être des tableaux, l'appel à la fonction doit inclure la construction "array" et peut être divisé en plusieurs ligne pour améliorer la lecture. Dans ces cas, les standards d'écriture de tableaux s'appliquent aussi :

Les structure de contrôles basées sur les constructions if et elseif doivent avoir un seul espace avant la parenthèse ouvrante de la condition, et un seul espace après la parenthèse fermante.

Pour la condition entre les parenthèses, les opérateurs doivent être séparés par des espaces pour une meilleure lisibilité. Les parenthèses internes sont conseillées pour améliorer le regroupement logique de longues conditions.

L'accolade ouvrante est écrite sur la même ligne que la condition. L'accolade fermante est toujours écrite sur sa propre ligne. Tout contenu présent à l'intérieur des accolades doit être indenté par 4 espaces.

If the conditional statement causes the line length to exceed the maximum line length and has several clauses, you may break the conditional into multiple lines. In such a case, break the line prior to a logic operator, and pad the line such that it aligns under the first character of the conditional clause. The closing paren in the conditional will then be placed on a line with the opening brace, with one space separating the two, at an indentation level equivalent to the opening control statement.

The intention of this latter declaration format is to prevent issues when adding or removing clauses from the conditional during later revisions.

Pour les instruction "if" qui incluent "elseif" ou "else", les conventions de formatage sont similaires à celles de la construction "if". Les exemples suivants montrent le formatage approprié pour les structures "if" avec "else" et/ou les constructions "elseif" :

Les instructions de contrôle avec "switch" ne doivent avoir qu'un seul espace avant la parenthèse ouvrante de l'instruction conditionnelle, et aussi un seul espace après la parenthèse fermante.

Tout le contenu à l'intérieur de l'instruction "switch" doit être indenté avec 4 espaces. Le contenu sous chaque "case" doit être indenté avec encore 4 espaces supplémentaires.

La construction default ne doit jamais être oubliée dans une instruction switch.

NOTE : Il est parfois pratique d'écrire une clause case qui passe à travers le case suivant en omettant l'inclusion de break ou return. Pour distinguer ce cas d'un bug, toute clause case ne contenant pas break ou return doit contenir le commentaire "// break intentionally omitted".

Tous les blocs de documentation ("docblocks") doivent être compatible avec le format phpDocumentor. La description du format phpDocumentor n'est pas du ressort de ce document. Pour plus d'information, visitez » http://phpdoc.org/

Tous les fichiers de code source écrits pour Zend Framework ou qui opèrent avec ce framework doivent contenir un docblock du fichier, en haut de chaque fichier, et un docblock de classe immédiatement au dessus de chaque classe. Ci-dessous vous trouverez des exemples de tels docblocs.

Chaque fichier qui contient du code PHP doit avoir un bloc d'entête en haut du fichier qui contient au minimum ces balises phpDocumentor :

Chaque classe doit avoir un docblock qui contient au minimum ces balises phpDocumentor :

Chaque fonction, méthode, doit avoir un docblock contenant au minimum :

• Une description de la fonction

• Tous les arguments

• Toutes les valeurs de retour possibles

Il n'est pas nécessaire d'utiliser la balise "@access" parce que le niveau d'accès est déjà connu avec les constructions "public", "private", "protected" utilisée pour déclarer la fonction.

Si une fonction/méthode peut lancer une exception, utilisez "@throws" :