Meilleures pratiques de programmation

Référence en anglais : 17 Janvier 2009 - 00h33 - http://drupal.org/node/287350


Cette page expose brièvement nos meilleures pratiques pour programmer avec Drupal. Cela concerne autant des questions de haut niveau que celles abordées dans les pages Normes de programmation et Configuration & Usage Best Practices.

Le but de ces pages n'est pas de vous apprendre à programmer mais de de vous apprendre à devenir un meilleur programmeur dans le framework Drupal.

Tout le monde peut écrire du code, mais peu savent qu'il y a une façon de faire avec Drupal. Pourquoi la vitesse et les performances sont-elles si importantes ? Pourquoi documenter le code-source ? Pourquoi ce bout de code si utilisé est-il mauvais ? Nous répondons ici à ces questions, et à plein d'autres encore, et nous expliquons pourquoi.

Plan proposé

Connaître son API; ne pas réinventer la roue

Référence en anglais : 10 octobre 2008 - 17h17 -


Connaître l'API de Drupal n'est pas une tâche titanesque. La consulter chaque fois que vous pensez en avoir besoin est fortement conseillé. N'essayez pas de résoudre à tout prix les différentes questions de programmation par du codage brut. Au lieu de cela, chaque fois que vous pensez écrire plus de fonctions qu'il n'y en a besoin, arrêtez-vous et consultez la documentation de l'API pour voir s'il n'y a pas une façon de contourner votre problème. Si vous travaillez avec des modules contributifs, parcourir l'index des modules contributifs peut aider.

Admettez-le. Vous êtes intelligent mais il y a de bonnes chances que quelqu'un d'autre, quelque part, ait déjà essayé de faire ce que vous faites; et l'ait écrit dans une API. Vous pouvez avoir besoin d'une simple fonction, ou d'une série de fonctions, mais puisque l'un des buts d'une bonne programmation est la robustesse d'un code, utilisez l'API chaque fois que vous en aurez l'occasion.

Nommez les fonctions, nommez les variables

Référence en anglais sur drupal.org :27 Mai 2009 - 02h13 - http://drupal.org/node/299070


Nommez vos variables correctement

Choisir un nom adéquat pour vos fonctions est très important. Mais vous devriez apporter le même soin aux noms des variables. N'utilisez pas simplement $i et $j à tout bout de champ. Le nom de la variable doit clairement faire allusion à ce qu'elle contient. Si possible, regardez dans le core pour avoir un exemple des conventions de nommage des variables et utilisez les mêmes conventions dans votre code-source.

Faites également attention aux mots réservés, leur utilisation à mauvais escient vous mènera à des problèmes insoupçonnables et impossibles à débogguer.

Choix grammaticaux

Faites attention aux singuliers et aux pluriels pour le nom des scalaires et des tableaux, vous pouvez éviter des erreurs de programmation en adoptant une « écriture grammaticale » cohérente.

Class vs Variable globale

Vous pouvez aussi utiliser une classe plutôt que des variables globales. Vous pouvez ainsi nommer les variables sans avoir besoin de les préfixer avec le nom du module puisqu'il est contenu dans l'objet. Utilisez les fonctions magiques _set, _get et _toString pour contrôler les paramètres des variables via un tableau privé.

Plus c'est petit, mieux c'est

Référence en anglais sur drupal.org : 9 Janvier 2009 - 10h00 - http://drupal.org/node/299074


Si l'implémentation d'une fonction ne tient pas sur un écran de votre éditeur, c'est probablement qu'elle essaie de faire trop de choses. Elle devrait être divisée en fonctions plus petites.

  • Si elle tient sur un écran, vous pouvez être sûr que chacun comprendra ce qu'elle fait (et pourra la débogguer si quelque chose ne va pas).
  • Des petites fonctions qui ne font qu'une chose sont plus faciles à tester.
  • Des petites fonctions qui ne font qu'une chose sont plus facilement réutilisables.

Les traductions sont impératives

Référence en anglais sur drupal.org : 23 Août 2008 - 17h24 - http://drupal.org/node/299085


Accessibilité des chaînes de caractères

Drupal est disponible dans tous les pays du monde, et bien qu'il soit programmé en anglais, les chaînes de texte qu'il affiche sont traduites dans presque toutes les langues que vous pouvez envisager. La fonction t() est obligatoire pour toutes les chaînes de caractères qui seront lues par un utilisateur ou un administrateur, et c'est la seule façon qu'a le core pour traduire les chaînes en quelque chose de lisible par les lecteurs.

Sécurité des chaînes

t() est non seulement indispensable pour la localisation, mais dispose de fonctionnalités de sécurité importantes que chaque développeur Drupal devrait connaître et comprendre. Il est plus simple d'intégrer les textes dès le départ dans une fonction t() que de revenir dans le code ultérieurement pour le faire si vous (ou quelqu'un d'autre) décidez d'utiliser une autre langue.

Utilisez le contrôle de versions

Référence en anglais sur drupal.org : 23 Août 2008 - 16h57 - http://drupal.org/node/299067


Quand vous écrivez du code-source, placez-le dès que possible dans un système de contrôle de version et committez-le au fur et à mesure, avec des messages explicites sur ce que vous changez et pourquoi. N'attendez pas d'avoir votre release 1.0 pour tout committer d'un coup - le but d'un contrôle de version est de maintenir un historique de vos changements, de vos décisions et de leurs raisons.

Faîtes-en usage dès le début de votre projet. Ainsi, lorsque vous aurez besoin, des mois plus tard, de débogguer, modifier ou améliorer quelque chose, vous serez content de pouvoir comprendre ce que vous aviez fait initialement et les raisons pour lesquelles vous l'aviez fait.

Voir la conception initiale de votre code-source peut également aider d'autres personnes, qui voudront l'étendre, l'améliorer ou le débogguer.

Enfin, cela vous servira également de sauvegarde hors-site pour votre travail. Votre portable peut être volé ou exploser en plein vol, vos supers-idées seront toujours à l'abri dans le dépôt. N'oubliez pas que si un code-source n'existe pas en différents endroits, il n'existe pas du tout.

Écrire du code efficace

Référence du document en anglais sur drupal.org : 4 Mai 2009 - 08h19 - http://drupal.org/node/328206 - Incomplet


Dans le monde des programmeurs il y a une course. Une course pour savoir qui écrira le code qui s'exécutera le plus vite possible. Pas seulement le code le plus rapide, mais le code le plus utile. Et si vous êtes programmeur, qui est votre adversaire ? Vous bien sûr !

En tant que programmeurs, nous cherchons non seulement à écrire un code qui fasse quelque chose, mais aussi à ce qu'il le fasse bien. Nous parlons de ce «bien» en tant qu'efficacité. L'efficacité s'entend comme vitesse, économie de moyens et objectifs. Les trois doivent évoluer en harmonie. Et dans le cas de Drupal, la vitesse est très importante car nous ne voulons pas faire attendre l'utilisateur ou déclencher un timeout du serveur. Les objectifs sont également importants car Drupal n'est rien s'il ne peut rien proposer d'utile à son public.

Il y a une façon à considérer: celle d'un produit concret. Supposons que vous possédez une entreprise qui fabrique un produit B. Votre entreprise, comme toute entreprise qui fabrique des produits, est remise en question : produisez-vous beaucoup de produits B vraiment rapidement, ou votre produit B est-il très utile.

Dans un monde sans frontières nous devrons faire le maximum possible. Malheureusement, la fabrication du produit B ne tient pas compte des deux idées en même temps, d'où une limite. L'entreprise devra alors dépenser du temps et des efforts pour trouver le point d'équilibre. Un point d'équilibre dont nous connaissons les éléments : prix des éléments, travail, valeur et autres facteurs. Ainsi, une fois ces questions réglées, l'entreprise adapte ses méthodes de fabrication pour produire le plus de produits B tout en améliorant sa qualité.

Le parallèle avec le monde de la programmation est là (Ah. Je me disais aussi. NdT). Vous programmez pour atteindre un objectif (l'objectif est le produit B). Vous pouvez aussi programmer pour apporter une incroyable vitesse et d'aussi incroyables objectifs (et nous supposons que la qualité fait partie des objectifs).

Cependant, étant donné les limites des technologies modernes, vous ne pouvez obtenir les deux à la fois. Vous devez donc trouver votre point d'équilibre car vous ne pouvez obtenir les deux : la vitesse seule n'est rien s'il n'y a pas quelque chose à proposer, et proposer quelque chose ne doit pas prendre des plombes. Ceci - trouver le point d'équilibre - est ce que les pages suivantes de ce chapitre traiteront.

Les sujets présentés ici se rapportent à des problèmes simples à comprendre, qui seront également décrits. Ces sujets et problèmes incluent, entre autres, l'efficacité de la recursivité, le travail avec un ensemble de données sans rapport. En programmation, les problèmes peuvent facilement se résumer en une simple question, pourtant la plus simple des questions peut parfois demander des tonnes de réflexion pour être résolue.

Si vous avez un sujet relative à l'efficacité que vous voudriez voir ici (sur drupal.org ! NdT) n'hésitez pas à publier un commentaire sur cette page, d'aller en parler sur IRC, ou même d'ajouter cette page vous-même, si vous vous sentez au point sur le sujet.

(Ah oui, ça valait le coup de traduire ça. Vivement la suite. NdT)