Partie 1 : 10 conseils pour mieux coder en PHP !

Écrire du code peut parfois être la partie la plus difficile de tout processus de développement logiciel. Si vous n’êtes pas du tout organisé, et ce dès le début, en particulier pour les grands projets, alors sachez que vous allez pouvoir perdre beaucoup de temps, et possiblement vous rendre un véritable casse-tête si vous ne suivez pas les principes de bases des procédés de codage et de la gestion de code.

Un bon code est maintenable, réutilisable et vérifiable. Les conseils qui suivent portent sur la façon dont vous et/ou votre équipe de développement peut gérer diverses tâches de codage et la façon de garder aussi propre que possible votre code. Je vais vous présenter quelques « meilleures pratiques », issues de mon expérience personnelle et professionnelle, qui je l’espère vous aideront à mieux écrire du code et aider, vous et votre équipe à être efficaces.

1 – Utilisez une norme de codage

Il est facile d’écrire mal, et de produire un code non organisé ! Mais, il est plus difficile de maintenir un tel code. Un bon code suit généralement une norme qu’il s’agisse des conventions de nommage, du formatage, etc… Ces normes, communément nommées les « règles de bonnes pratiques » sont faites pour vous simplifier la vie parce qu’elles permettent de rendre clair et lisible votre code.

Si vous pouvez créer vos propres règles de codage, il est préférable de s’en tenir, ou du moins s’inspirer, de ce qui existe, et qui a été approuvé par beaucoup ! Ainsi, des normes proposées par Zend Framework Coding Standard ou prochainement le PSR-1 Coding Style Guide permettront de rapidement vous approprier du code tiers, et aux autres de s’adapter à votre code !

2 – Écrire des commentaires utiles

Les commentaires dans un code sont cruciaux ! Vous ne les apprécierez pas avant de laisser votre sac de nœud de lignes pendant deux ou trois jours, et que vous y reveniez tout en essayant de donner un sens à ce que vous avez noté ! Vous me prenez sûrement pour un fou, mais c’est vraiment ce qui se passe tous les jours. Faites vous-même le test ;) Les commentaires sont donc utiles pour faciliter votre vie, mais également ceux après vous qui devront maintenir votre code.

Écrivez des commentaires pour des lignes significatives, les simples n’ont aucun sens ; décrivez les paramètres aussi complets que possible, décrivez les fonctionnalités des fonctions et des méthodes ; commentez des blocs délicats et pour lesquels la logique n’est pas aussi triviale qu’on pourrait le penser.

3 – Refactorisation

Partie 1 : 10 conseils pour mieux coder en PHP ! - Refactorisation

La refactorisation (anglicisme venant de refactoring) est une opération de maintenance du code. Ce principe doit être une habitude pour tout les développeurs ! Croyez-le ou non, vous devriez refactoriser votre code quotidiennement, sinon ce dernier ne peut que perdre en qualité (même si vous pensez être le meilleur développeur du monde) ! Le refactoring maintient la qualité de votre code, mais qu’est-ce qui doit-être refactorisé et comment ?

Vous devriez tout refactoriser, qu’il s’agisse de l’architecture de vos méthodes et fonctions, des noms de variables, mais également le nombre d’arguments d’une méthode, etc…

Pour la réponse à « comment factoriser ? », sachez qu’il s’agit plus d’un art qu’une science, mais il y a quelques règles d’or qui peuvent nous éclairer à ce sujet :

  • Si votre fonction ou méthode dépasse les 20 à 25 lignes, il est probable que vous incluez trop de logique à l’intérieur, et vous pouvez probablement la scinder, en deux ou plusieurs fonctions/méthodes plus petites
  • Si le nom de votre méthode/fonction dépasse les 20 caractères, vous devez la repenser, peut-être que la logique de ce qu’elle fait rejoint la première affirmation…
  • Si vous avez un grand nombre de boucles imbriquées, autrement dit une complexité élevée, sachez qu’il y a toujours des conditions de retour à passer en priorité. En général, vous ne devez pas dépasser plus de deux boucles imbriquées. Trois boucles imbriquées seraient tout simplement horribles !
  • Considérez s’il y a des patterns de conception applicables dans quasiment toutes les situations. Bien sûr, vous ne devez pas utiliser ces derniers pour le simple plaisir d’utiliser des modèles, mais sachez qu’ils offrent des solutions aisées qui pourraient être applicables dans votre cas

4 – Évitez les globales

Les variables, les boucles, etc, globales sont autant de problématiques dès lors que votre application se développe à des millions de lignes de code. Elles peuvent influencer un code « ailleurs » dont il est difficile de discerner, ou de provoquer quelques affrontements sur le nommage. Réfléchissez à deux fois avant de polluer l’espace de noms global avec des variables, des fonctions, des boucles, etc..

Dans un cas idéal, vous ne devriez avoir aucun des blocs définis globalement. Toutes les déclarations telles que le switch, try-catch, foreach, etc…, doivent être écrites dans une méthode ou une fonction. Les méthodes doivent être écrites dans des définitions de classe, et les définitions de classe et la fonction doivent être dans des espaces de noms.

5 – Utilisez des noms significatifs

Ne jamais utiliser des noms comme , , et pour les variables. Comment allez-vous lire le code à l’avenir ? Et votre collègue ? Un bon code doit être significatif en termes de noms de variables, de noms de méthodes/fonctions et des noms de classe. Quelques bons exemples de noms significatifs sont les suivants : $request , $dbResult et $tempFile (selon vos directives de style de codage l’écriture de ces derniers peuvent légèrement être modifiée).

À noter, que faire du franglais ce n’est pas l’idéal ! Soit vous mettez tout en anglais, dès lors que le domaine de votre application le permet, soit en français. Dans certains cas, il est difficile de traduire un terme d’un domaine spécifique en français, je pense au médical notamment (n’est-ce pas Fabien ;) !

Voici quelques-unes des meilleures pratiques que j’essaie de mettre en œuvre quotidiennement ! Je vous fournirais la suite de la liste dès demain ! N’hésitez pas à apporter votre expérience dans ce domaine.

  • NaSH

    On est quand même pas mal aidé sur une norme de codage quand on utilise un bon IDE.
    Netbean m’aide pas mal dans ce cas.

    Par contre concernant le nommage des variables, y’a a redire ! en effet il est préférable que le nom soit significatif au niveau du typage, pour connaitre le type d’un coup d’oeuil!
    certe le PHP est auto-typé, mais au moins, on a pas a réapprendre quand on passe a un autre langage typé (genre python!)
    par ex : $iCompteur pour un integer, ou $sNom pour un nom, $aTableau, etc..

    les commentaires sont utile, mais si on peux les écrire de façon normalisée avec un outil d’autodocs comme phpdoc, c’est encore mieux. la documentation technique sera auto-généré, et on gagne un temps fou !

    la refactorisation c’est bien, mais trop c’est mal.
    le code doit être lisible, facilement maintenable et compréhensible. Plus de 20 lignes ce n’est pas grave. Si on perd 2 jours a comprendre ce qu’on a fait, on ne gagne rien. tout dépend si vous faite un simple site web, ou un traitement complexe de donnée pour un export destiné a une entreprise.

    • gcopin

      Les noms de variable ne doivent surtout pas contenir de typage, de couleur ou autre. Dans l’optique d’une refactorisation, justement, le typage peut changer… et là, c’est le drame ;)

  • Pingback: advisa | technologie » Blog Archive » Partie 1 : 10 conseils pour mieux coder en PHP !

  • http://twitter.com/tanguy_martin Tanguy Martin

    Article intéressant et pour les anglophiles, PHP: The Right Way est aussi une bonne lecture sur le même sujet : http://www.phptherightway.com/

  • Cali

    Tres pratique pour les normes de codage : webcodesniffer (http://www.webcodesniffer.net), la version web de php code sniffer. Vous avez le choix entre le version en ligne ou la version a installer sur votre WAMP (http://www.easyphp.org)

  • http://blogmotion.fr Mr Xhark

    (Le lien vers
    PSR-1 Coding Style Guide est mort à priori)

    • http://www.blog-nouvelles-technologies.fr Yohann Poiron

      Modifié ! Désolé…

  • Pingback: Partie 2 : 10 conseils pour mieux coder en PHP !- Le blog des nouvelles technologies : Web, Technologies, Développement, Interopérabilité

  • Frédéric Bruyère

    Au début du point #5: « Ne jamais utiliser des noms comme , , et pour les variables » les noms ($a $b $c et $test) n’apparaissent pas :)

  • Pingback: Partie 1 : 10 conseils pour mieux coder en PHP !- Le blog des nouvelles technologies : Web, Technologies, Développement, Interopérabilité | Le blog Mywesoft

  • Pingback: Émission #20 du 27 septembre 2012 – Se péter la marboulette

  • Amine

    Je ne comprends pas pourquoi les varibales globales sont une mauvise pratiques,
    On peut trouver des CMS qui utilisent beacoup les variables globales comme wordpress