Zend Framework 2 - règles de codage

Développement des applications web avec Zend Framework 2

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
Zend a dévoilé la nouvelle version de son framework bien après Sensio Lab et son Symfony2. Il est donc le temps de bien se mettre dans le bain et commencer le développement avec le nouvel outil du Zend. Cependant, avant de le faire, il est nécessaire de connaître quelques règles de développement des applications web avec Zend Framework 2.

Déjà la première version du framework contenait l'ensemble des règles qu'il fallait respecter pour développer les applications. Ces principes ont pour but de garantir une meilleure pérennité du projet. Les développeurs passant par le projet n'ont pas à découvrir à chacun son tour la spécificité du code. Ensuite, cette clarté garantit également une meilleure maintenabilité pour des programmeurs déjà sur place. Et dans le cas d'une vente, cela peut être un argument commercial car la nouvelle équipe ne devra pas consacrer du temps à comprendre pourquoi les noms des fonctions sont écrites en camelCode.

Regardons donc quelques règles d'or auxquelles devront répondre les applications développées sous Zend Framework 2 :

  1. Eviter d'utiliser le tag fermant pour PHP.
    Il est conseillé de ne pas utiliser le tag fermant pour le code des contrôleurs et autres composants de l'application. Il s'agit de la balise ?>. Cette opération doit garantir les problèmes qui peuvent apparaître à cause des espaces blanches rajoutées dans la réponse.

  2. Régles d'écriture du code
    L'indentation du code ne peut pas être basée sur les tabulations. Chaque développeur peut configurer son éditeur différemment et pour certains le code peut ressembler à un beau poème difficile à comprendre. C'est pourquoi dans ses recommandations, Zend encourage les programmeurs à utiliser l'indentation composée de 4 espaces blanches.

    Pour les soucis de lecture également, chaque ligne de code ne devrait pas dépasser 80 caractères. Dans les cas justifiés, il est admis de rallonger cette limitation à 120 caractères.

  3. Règles concernant les classes
    Les classes doivent correspondre à leur emplacement physique. Par exemple, pour une classe possédant l'espace de nom suivant My\Logger\Reader on devrait pouvoir retrouver un fichier dans le chemin My/Logger/Reader.php. Chaque fichier ne peut contenir qu'une seule classe.

    Les noms des classes ne peuvent être composés que des caractères alphanumériques. Cependant, l'utilisation des chiffres est fortement déconseillée. Contrairement à la version précédente du framework, les underscores (_) ne seront pas traduites en séparateurs des répertoires. Cela veut dire que la classe My/Logger_Reader sera placée dans le répertoire My et non pas My/Logger.

    Concernant les noms composés des classes. Chaque nouveau mot doit commencer par une lettre majuscule, par exemple : LoggerDoc et non pas loggerDoc.

    En ce qui concerne les classes abstraites. Les noms de ces classes doivent être préfixés par le mot Abstract. Par exemple : AbstractLogger pour une classe abstraite d'un loggeur.

    Les interfaces ont également une spécificité de nommage. Elles doivent être suffixées par le mot Interface. Si l'on reprend l'exemple du loggeur, on aura une interface LoggerInteface. En plus de cela, elles doivent être soit les noms, soit les adjectives. On ne pourra donc pas avoir une interface nommé WriteLogInterface. La version correcte sera LogWritterInterface.

  4. Règles concernant les méthodes et les variables
    Les conseils concernant le nommage des méthodes et des variables sont communs. Chaque nom doit commencer par une lettre minuscule. S'il s'agit du nom composé, chaque nouveau mot doit commencer par une lettre majuscule. Les noms ne peuvent contenir que des caractères alphanumériques. Comme dans le cas des classes, les chiffres sont admis pas déconseillés.

    Les noms peuvent également contenir les underscores (_). Par exemple, ce caractère peut servir comme un signe distinctif pour des propriétés et méthodes privées et protégées. Cependant, c'est également déconseillé par Zend. En fait cette volonté de marquer les propritétés privées et protégées peut poser pas mal de soucis dans le cas de rafactorisation du code où l'on voudra, par exemple, les convertir en propriétés publiques.

  5. Règles concernant les constantes
    Des recommandations différentes concernent les constantes des classes. Précédées par le mot-clé const, leurs noms doivent être écrits en majuscules. Ils peuvent contenir des underscores (_) comme remplacement des espaces blanches. Les chiffres sont admis.

  6. Règles concernant les tableaux
    Une règle intéressante concerne l'écriture des tableaux. Pour la définition des tableaux sur une seule ligne, le problème ne se pose pas. Par contre, l'initialisation des tableaux sur plusieurs lignes peut être problématique. Pour remedier à cela, Zend conseille de définir tous les composants du tableau à la même hauteur, comme sur cet exemple :
    $myArray = array("test", "toto",
    "moto", "mete");

    On peut également utiliser l'écriture qui définit les composants du tableau à l'intérieur des parenthèses :
    $myArray = array(
    "test", "toto",
    "moto", "mete"
    );

    Ici il faut que la parenthèse fermante correspond à la colonne dans laquelle se situe le première caractère de la variable (en occurrence $). Les composants du tableau doivent commencer sur une nouvelle ligne, avec une indentation de 4 espaces blanches.

    Les mêmes recommandations s'appliquent aux tableaux associatifs.


Les conseils de Zend sont à prendre au sérieux. C'est grâce à eux qu'une application a une chance de devenir quelque chose de plus qu'une application web. C'est aussi grâce à eux que PHP peut gagner du respect dans le monde entrepreneurial.
Bartosz KONIECZNY 30-09-2012 10:43 Zend Framework 2
Moi

Développeur d'applications Internet et journaliste passionné par l'adjectif français. Un aigle polonais orienté vers la progression, volant très haut et écoutant du zouk après les matches du foot français.

Vous appréciez mon travail ?

Pour contribuer au développement de ce site, ou pour remercier pour des articles rédigés, vous pouvez faire un don.

Un conseil JavaScript

Comment supprimer un élément style sous jQuery ?

Ce framework JavaScript permet de manipuler facilement les attributs d'un élément. On peut par exemple spécifier la position de l'image de fond pour l'attribut "style" :

$('#newBackground').css('background-position' , '0 -28px');
Comment faire pour supprimer cet attribut, par exemple dans une fonction callback ? Rien de compliqué, car il suffit tout simplement de passer une valeur vide :
$('#newBackground').css('background-position' , '');