Pourquoi s’embêter avec le chargement automatique dans WordPress, partie 1
L’une des choses les plus simples que nous puissions faire lorsque nous travaillons sur des plugins WordPress est de supprimer les instructions require_once ou include_once dans notre code.
Et pourquoi pas? C’est un moyen facile d’apporter tous les fichiers ou dépendances nécessaires pour une classe donnée, de les rendre facilement lisibles et de ne pas avoir à se soucier de créer d’énormes fichiers de code. Autrement dit, cela nous aide à simplifier ce que nous écrivons afin que nous puissions faire en sorte que nos classes fassent [principalement ou idéalement] ce qu’elles font bien.
Si vous avez lu ce site au cours de la dernière année, vous savez que je suis un fan du chargement automatique et que je pense que toute personne travaillant avec PHP – que vous utilisiez WordPress ou une autre plate-forme – devrait utilisation.
Mais cela soulève deux questions, surtout si vous débutez :
- Pourquoi s’embêter avec le chargement automatique alors qu’il existe d’autres façons de gérer les dépendances de chargement ?
- Comment le chargement automatique se compare-t-il aux langages compilés ?
J’ai donc pensé qu’il valait la peine d’y répondre dans les prochains articles.
Pourquoi s’embêter avec le chargement automatique ?
Le court c’est ceci:
- require_once et include_once peuvent conduire à un code difficile à déboguer,
- il est difficile de tracer le code.
Mais comment ça ?
1 Le débogage est difficile
Lors de l’écriture de code, si quelque chose est certain, c’est qu’il y aura quelque chose qui ne fonctionnera pas comme prévu. C’est dans la nature de ce que nous faisons, n’est-ce pas?
Donc, quand vient le temps de déboguer du code, nous avons tous nos stratégies.
- certains d’entre nous choisissent d’utiliser echo ou var_dump pour tracer le code,
- utiliser un plugin dans WordPress,
- d’autres utilisent un débogueur.
Bien que cet article ne traite pas de la façon de déboguer, c’est le fait que nous devons déboguer. Donc, si nous savons que nous allons devoir le faire, ne devrions-nous pas nous faciliter la tâche autant que possible ?
PHP est un langage typé dynamiquement, donc il y a beaucoup de choses, en général, qui sont prises en charge pour nous chaque fois que nous écrivons le code. C’est-à-dire que certaines choses sont déduites ou forcées chaque fois que le code est exécuté.
Par exemple, supposons que vous travaillez avec une chaîne et que vous la comparez à un nombre. L’interpréteur fera ce qu’il peut pour deviner ce que vous faites (cherchez-vous à analyser la chaîne en un entier ou vice versa ?), puis travaillera avec cela.
Travailler avec des variables seules peut être un exercice de précision car nous voulons que notre code se lise comme nous le souhaitons. Pourquoi laisser à l’interprète le soin de deviner ce que nous voulons dire? Et si l’interprète doit faire un travail supplémentaire, les humains le font certainement.
À cette fin, si nous savons que des bogues vont être introduits et qu’il existe des moyens d’écrire du code plus propre, pourquoi ne le ferions-nous pas ?
2 Le traçage est difficile (ou peut-être plus difficile ?)
Mais cela ne fournit toujours pas de raison pour laquelle nous devrions nous fier à quelque chose comme un chargeur automatique par rapport aux fonctionnalités intégrées du langage, n’est-ce pas ?
Considérez ceci : supposons que vous parcouriez un fichier en essayant de trouver un bogue et que vous rencontriez une fonction qui contient du code, utilise include_once, puis utilise un autre code.
Cela signifie que vous devez lire le code, le conserver mentalement, sauter dans un autre fichier, comprendre ce code, puis revenir au fichier d’origine. Et cela suppose que le deuxième fichier n’inclut pas ou ne nécessite pas d’ autres fichiers non plus.
C’est ce qu’on appelle le code spaghetti pour une raison.
Cela dit, vous pouvez voir la situation difficile que cela introduit lorsque vous choisissez d’imbriquer ce code dans le reste de votre programme. En bref, vous avez imbriqué l’inclusion de dépendances, ce qui rend intrinsèquement plus difficile le suivi d’un problème.
Cela ne veut pas dire que le chargement automatique résout automatiquement ce problème, mais cela signifie que cela ne doit pas nécessairement être comme ça. Au lieu de cela, vous pouvez écrire du code qui instancie des classes, appelle des méthodes, puis exécute du code sans avoir besoin d’inclure quoi que ce soit manuellement.
Code plus lisible et traçable
Ce faisant, je trouve que cela nous oblige à écrire un code plus propre, sans doute un code plus maintenable. Cela facilite également l’écriture de code que nous pouvons tracer plus facilement, et qui est plus facile à exploiter avec un débogueur.
Autrement dit, nous pouvons définir des points d’arrêt à certains endroits de notre code, faire en sorte que le débogueur nous emmène automatiquement dans la classe invoquée et revenir dans la fonction qui l’appelait.
Cela ne signifie pas qu’il ne peut pas être fait autrement, mais les avantages l’emportent largement sur les alternatives. Et, bien sûr, cela laisse toujours la question de savoir pourquoi le chargement automatique (ou toute inclusion de fichiers tiers) est nécessaire.
Mais c’est ce qui sera couvert dans la deuxième partie de la série.
Autre lecture
Mon article sur les espaces de noms et le chargement automatique dans WordPress, ainsi que le Simple Autoloader pour WordPress, sont deux autres ressources que je trouve évidemment liées à cet article particulier. Donc, si vous avez le temps, jetez-y un œil (et n’hésitez pas à ouvrir un ticket ou une pull request sur le projet simple autoloader).