É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
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 $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.
