fermer
DéveloppementOutils - Conseils

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.

Tags : bonnes pratriquescodagedéveloppementnormePHPrègles
Yohann Poiron

The author Yohann Poiron

J’ai fondé le BlogNT en 2010. Autodidacte en matière de développement de sites en PHP, j’ai toujours poussé ma curiosité sur les sujets et les actualités du Web. Je suis actuellement engagé en tant qu’architecte interopérabilité.