Tout développeur, que ce soit à l’école ou en apprenant sur le tas, écrit du code. J’espère n’avoir perdu personne à ce stade de l’explication

Inconsciemment on cherchera à utiliser un style d’écriture avec lequel on se sent à l’aise, qu’on pourra et saura relire facilement et dans le meilleur des cas, qui pourra être relu par une autre personne sans avoir à engager d’interprète.

Tout développeur tend donc à utiliser des conventions de programmation (coding standards), que ce soit en HTML, PHP, CSS, JavaScript ou même en Cobol. Et utiliser des conventions, c’est bien !

Quelle convention de nommage adopter ?

Avant de choisir une convention, encore faudrait-il savoir quelles conventions existent :

• pas de convention
• convention hongroise
• convention PEAR
• convention symfony
• convention Zend Framework
• convention WordPress (que j’abhorre)
• etc.

Autant dire qu’il y a de tout et pour tous les goûts.
Ce qu’il faut retenir d’une convention c’est qu’elle explicite des règles de développement :

• sur le nommage des éléments
• sur l’indentation des éléments
• sur les structures de contrôle (if, else, tout ça quoi)
• sur la syntaxe des commentaires
• sur la syntaxe de la documentation (le code auto-documenté c’est bon !)
• sur l’organisation des fichiers, éventuellement

C’est pour ça que partir sur une convention parfaite sur le papier mais inapplicable est une vaste fumisterie. L’idéal étant de pouvoir reprendre du code dans un projet sans avoir eu besoin de lire la documentation pour en comprendre l’organisation.

Mon conseil : essayez, choisissez mais ne prenez pas non plus trop laxiste en terme de notation.
Une chose est sure : quand on a essayé une belle

Mes conventions de nommage en PHP

J’avoue, la notation utilisée dans symfony m’a tellement plu que je la réutilise quasiment partout. Ci-dessus, une illustration montrant du code pour un plugin WordPress (en PHP 4 malheureusement …). Elle en présente un bon aperçu.

Notation

J’utilise UpperCamelCase pour le nommage des classes sauf s’il y a un préfixe qui, lui, reste en minuscule.
Exemples : class AmazonWidgetsShortcodes, class sfUploader.

Pour ce qui est méthodes de classes, j’utilise lowerCamelCase. Comme ça on sait qu’on reste dans un objet et c’est pas plus mal.

Enfin, pour les fonctions orphelines, helpers & cie, c’est tout en minuscule séparé par des underscore (un nom particulier à ça ? lowered_and_underscored ? )
Exemple : add_filter()

Indentation

Dans l’indentation il y a 2 camps : celui des espaces et celui des tabulations.

J’ai suivi celui des espaces pour une simple et bonne raison : 1 tabulation a une taille différente selon les éditeurs, que ça soit votre IDE, votre shell ou n’importe quel logiciel de texte. L’idéal est d’avoir un rendu identique dans tous les éditeurs sans paramétrage.

En revanche, là encore je suis mais j’aime, je suis sur une tabulation à 2 espaces : c’est bête mais je trouve ça plus esthétique et on arrive moins rapidement à la limite de 80 caractères.

Cette « limite » n’est que virtuelle mais ouvrez un terminal, 80 lignes par défaut. C’est plus confortable de rester en-dessous de ce nombre. Ceci dit je fais quelques exceptions, des fois

Structures de contrôle

On pourrait résumer à 1 ligne = 1 action et 2 types d’utilisation.

Tout d’abord les structures dans le code à proprement parler :

• un espace entre l’opérateur et la parenthèse ouvrante
• un retour à la ligne à chaque accolade
• pas d’espaces dans les lignes vides (résidus d’indentation)
• systématiquement les accolades, même en cas de ligne unique après l’opérateur
• opérateur ternaire quand ça reste simple, pas trop long et plus lisible

Côté templating en revanche j’utilise la syntaxe alternative de PHP à raison d’un opérateur par ligne :

<ol class="posts">
<?php foreach($posts as $post): ?>
  <li id="post-<?php echo $post->getId() ?>">
    <a href="<?php $post->getPermalink() ?>">
      <?php echo $post->getTitle() ?>
    </a>
  </li>
<?php endforeach ?>
</ol>

Syntaxe de la documentation

Enfin, pour terminer sur la partie PHP, PHPDoc est surpuissante en plus d’être simple à utiliser. Comble du bonheur, sa syntaxe est réutilisable dans d’autres langages.

PHPDoc est le principe du code autodocumenté :

1. vous commentez votre code avec la syntaxe PHPDoc
2. vous générez sa documentation avec le programme PHPDoc (en HTML, PDF etc.)

L’idéal est de documenter en même temps qu’on produit le code. Par principe on revient rarement sur son propre code juste pour le loisir de le décrire, par manque de temps ou par flemme.

Mes conventions de nommage en JavaScript

Ne vous inquiétez pas, je ne vais pas tout recommencer pour JavaScript Je suis à peu près la même logique qu’en PHP à part pour les accolades.

En effet si je conserve un comportement similaire pour les structures de contrôles (1 accolade par ligne) :

• je ne fais pas de retour à la ligne sur les accolades/parenthèse ouvrante d’une fonction/objet anonyme
• je ne fais pas de retour à la ligne après une accolade/parenthèse fermante s’il y a une virgule ou parenthèse après

var OncleTom = {
  age:      25,
  pensee:   function(){
    return this.age * Math.random()
  }
};

Mes conventions de nommage en CSS

Inutile de paraphraser ce que j’ai déjà écris dans mon article sur les bonnes pratiques de codage CSS.

Deux lectures en une oui

Conclusion

Bon au final on voit que ce n’est pas si compliqué que ça d’apporter un brin de rigueur.
On pourra même s’amuser à compléter le tout par la disposition des méthodes et fonctions d ans un fichier par ordre alphabétique (j’en connais un que ça fera sourire ).

Les vues Outline fournissent un plan du code et certains logiciels ne semblent pas disposer d’une fonction de tri. Et au cas où un jour vous n’auriez pas votre IDE favori sous le nez, ça ne mange pas de pain de fonctionner ainsi.

Que l’on travaille seul à plusieurs, et à plus fortes raison dans ce dernier cas, l’utilisation de notations et conventions est un gage de qualité. Ça rend le travail plus facilement interopérable avec d’autres développeurs, plus facile à relire, plus facile à maintenir.

Ça n’empêchera jamais des bugs ou de sortir du mauvais code mais c’est ça, c’est une autre histoire.

Enfin, j’aimerais terminer cet article en écrivant qu’il a fait l’objet d’une chaîne par le Padawan PHPiste Damien Alexandre. C’était l’occasion de faire une réponse qui passe inaperçue

Ça ne m’empêchera en revanche pas de refiler la patate chaude à NicoDePrendreUnCafé, de tenter d’insuffler de l’activité au blog de Xavier Lacot, de Spipifier Gastero Prod, d’extirper une technique ninja pyjama à remouk et pourquoi pas lire avec attention l’avis pythonien de David Larlet ?

Et just for fun, un petit coup d’électrode à un de mes futurs étudiants, Thierry Poinot.

Il existe 4 phases dans la vie d’un développeur :

1. celle où il aime tout créer lui-même
2. celle où il aime utiliser un outil déjà tout prêt
3. celle où il aime concevoir son outil avec d’autres outils tout prêt
4. celle où il aime que les autres conçoivent pour lui (mais là il est patron ou armé d’une horde de stagiaires )

Les frameworks font partie de cette troisième catégorie. Ils existent dans à peu près tous les langages : CSS, PHP, JavaScript, Java, C#, Python, Ruby etc.
Mon discours portera sur les frameworks PHP, parce que c’est mon langage de prédilection mais aussi parce qu’un livre blanc sur les frameworks PHP pour l’entreprise est récemment sorti. Il parlera aussi bien aussi bien aux décisionnels qu’aux développeurs, à leur compte ou pour celui d’une entreprise.

De l’intérêt d’utiliser un framework

Un framework est littéralement ce que l’on peut appeler un socle logiciel : il propose des fonctionnalités de base et vous les utilisez pour concevoir votre propre application.

J’essaierai de faire court en énumérant une liste de quelques points à faire valoir dans l’utilisation d’un framework pour concevoir une application Web :

• développement accéléré
• convention over configuration : suivez les rails des conventions plutôt que de tout paramétrer
• DRY : écrivez le code une fois et réutilisez-le pour éviter le copier-coller (sans parler des gains de maintenabilité)
• mutualisation du code : un même socle pour plusieurs applications
• concentration du développement sur le code métier
• le framework vous décharge des tâches pénibles : sécurité, gestion des URL, gestion des permissions utilisateur, manipulation des bases de données, gestion du cache, accès aux fichiers etc.
• génération automatique d’interfaces (admin generator), de base de données (ORM), de modules/applications (scaffolding) etc.
• vecteur d’apprentissage individuel et collectif
• bénéfices de tout le travail d’une communauté … et de celui que vous réinjecterez

A contrario, on pourra critiquer les frameworks pour leur plus forte consommation en ressources qu’un développement maison.
Ce n’est évidemment pas une raison valable pour passer à côté d’autant plus qu’il existe de nombreuses solutions pour palier/réduire ce problème avec les gestionnaires de cache et les accélérateurs de code.

Framework PHP ou CMS ?

Maintenant vous me direz : pourquoi développer un logiciel avec un framework au lieu d’utiliser un bon CMS des familles ou tout autre logiciel faisant son office ?
Ce n’est à mon sens pas la bonne question à se poser : un framework n’est pas une fin en soi. Le choix du logiciel dépendra essentiellement du besoin, immédiat et futur. Vous aurez beau avoir le meilleur développeur d’un CMS de votre pays, si le choix de la solution technique est déjà erroné, il ne suffira pas à éviter la catastrophe.

J’ai beaucoup accroché à cette formule le jour où je l’ai entendu : si vous estimez à au moins 50% l’utilisation de spécifiques dans une solution logicielle existante de type CMS, vous faites fausse route. Le spécifique EST votre solution, le CMS devient une simple fonctionnalité.
Dans le cas d’un développement spécifique, le choix d’un framework est dans ce cas naturellement prescrit.

Dans tous les cas, ce sont vos besoins qui doivent vous guider vers le choix d’une solution et non l’inverse. Ne partez pas surtout d’une solution pour tenter d’y combler vos besoins.

Les principaux frameworks PHP

Le livre blanc sur les frameworks PHP expose en détail les frameworks majeurs en PHP avec leurs avantages, inconvénients et surtout une grille comparative permettant de mettre à bout à bout leurs différentes fonctionnalités.

Toutefois on peut retenir ces noms de frameworks PHP :

• CakePHP
• CodeIgniter
• EZ Components
• PEAR
• symfony
• Zend Framework

On pourrait classer ces frameworks en 2 catégories :

• les briques logicielles : ils se présentent comme des briques indépendantes qu’on peut utiliser à souhait dans n’importe quel projet, y compris d’autres frameworks. C’est notamment le cas de PEAR, EZ Components et Zend Framework ;
• les frameworks à proprement parler : ils imposent une structure particulière et des lignes directrices de développement pour être plus efficace. On citera dans ce cas symfony, CodeIgniter et CakePHP

symfony : champion toutes catégories

Lors de la lecture du livre blanc sur les frameworks PHP, vous remarquerez très probablement que le framework symfony a tout pour plaire. C’est en effet à l’heure où j’écris ces lignes le framework PHP le plus abouti et le plus intéressant à analyser.
Il jouit d’une excellente réputation, d’une incroyable stabilité et d’une communauté très active, quantitativement et qualitativement parlant. Si on ne devait en garder qu’un, ça serait lui.

Pourquoi j’apprécie énormément symfony :

• une documentation fonctionnelle et une documentation de l’API complètes
• utilisation intensive de fichiers YAML pour le paramétrage
• les fonctionnalités d’amin generator, de gestion de base de données avec l’ORM Propel et les outils d’automatisation qui en découlent
• facilité d’intégration d’Ajax sans pondre une seule ligne de JavaScript
• grand confort de développement
• des conventions inspirées des plus grands (Ruby on Rails, Django etc.)

Conclusion

Développeurs : renseignez-vous et intéressez-vous à au moins un framework. C’est bien pour le CV et vous gagnerez du temps.
Décideurs : exigez de savoir quelle solution on vous préconise et surtout, pourquoi celle-là. À plus forte raison si votre projet comporte beaucoup de besoins spécifiques, demandez s’il s’agit d’un framework et si ce n’est pas le cas, pourquoi ça n’a pas été envisagé. Vous gagnerez aussi du temps et j’espère de l’argent.

Les frameworks sont aujourd’hui partout et ont acquis une certaine maturité. Ces lettres de noblesse les rendent utilisables aussi bien pour des petits besoins que ceux d’entreprises, peu importe leur taille. Les gains de temps et l’incitation à la production de qualité sont des facteurs non-négligeables pour la pérennité de vos applications.

Attention toutefois : un mauvais développeur et/ou une mauvaise conception prédomineront toujours. Votre fromage industriel aura toujours le même goût, peu importe la qualité du pain

Je radote mais j’espère que vous trouverez suffisamment d’informations pour vous convaincre dans le livre blanc des frameworks PHP pour l’entreprise. C’est ce genre de publications qui me font aimer la société dans laquelle je travaille