Suggestions pour organiser le code de procédure
Pour autant que j’écris sur – et suis un fan de – la programmation orientée objet, je n’écris pas beaucoup sur l’époque où je travaille avec une base de code procédural.
La programmation procédurale est un paradigme de programmation, dérivé de la programmation structurée, basé sur le concept d’appel de procédure. Les procédures, également appelées routines, sous-routines ou fonctions, contiennent simplement une série d’étapes de calcul à effectuer.
Parfois, cela vient des exigences d’un projet, parfois d’un projet dont j’ai hérité, ou parfois à cause d’autre chose.
Je pense qu’il est important qu’en tant que programmeurs, nous ne maintenions pas un paradigme si élevé que nous hésitions à travailler avec d’autres façons d’écrire du code. Après tout, l’acte d’écrire du code consiste essentiellement à résoudre un problème.
La façon dont le problème est résolu peut être considérée comme secondaire.
Quoi qu’il en soit, chaque fois que je travaille avec une base de code; cependant, c’est écrit, j’essaie toujours de m’assurer qu’il est organisé de manière cohérente, aussi facile à suivre que possible et qu’il puisse être maintenu dans le temps.
J’ai pensé que je partagerais comment j’aborde l’écriture de plugins WordPress en utilisant la programmation procédurale par rapport à la programmation orientée objet et comment je m’y prends pour organiser le code procédural.
Si rien d’autre, cela vous donnera peut-être quelques idées pour un projet en cours ou futur.
Code de procédure d’organisation
Lorsqu’il s’agit de travailler avec du code procédural, il y a beaucoup de potentiel pour inclure presque tout dans un seul fichier monolithique.
Je ne suis pas de cette approche car il est plus difficile de trouver où se trouve quelque chose dans le fichier (du moins si vous êtes quelqu’un qui vient d’entrer dans un projet).
À cette fin, ce sont les choses que je fais habituellement.
- Actions et filtres séparés. En règle générale, je prendrai toutes les actions et les placerai dans un fichier et je prendrai tous les filtres et les placerai dans un autre fichier. Il est également possible de séparer davantage ces fichiers dans des sous-répertoires (sinon des espaces de noms également) en fonction de leurs domaines d’intérêt. Par exemple, toutes les actions liées à la zone d’administration peuvent aller dans un sous-répertoire admin .
- Écrire un fichier de débogage. J’inclus normalement un script de débogage simple dans un plugin afin de pouvoir facilement afficher les informations de débogage à l’écran, écrire dans le fichier journal de débogage ou écrire dans les deux. Cela peut être une commodité si rien d’autre, mais cela aide à fournir un moyen de voir facilement ce qui se passe sans avoir besoin de lancer Xdebug et de parcourir le code (sauf s’il s’agit d’un problème plus compliqué).
- Chargeur automatique. Si vous utilisez du code procédural, vous n’utilisez peut-être pas du tout d’espaces de noms, mais si c’est le cas, j’inclus également un chargeur automatique que j’ai écrit pour faciliter l’inclusion automatique de fichiers. Ceci est différent du chargeur automatique généré par Composer, mais il fait toujours la même chose.
De toute évidence, il n’y a rien de fondamentalement compliqué dans les recommandations ci-dessus. En fait, je dirais que n’importe lequel des éléments ci-dessus, en particulier la première étape, peut grandement contribuer à améliorer la gérabilité du code procédural.
Le fichier principal du plugin
Si vous choisissez de faire tout ce qui précède, la version finale du fichier d’amorçage du plugin devrait être très simple. En fait, cela peut ressembler à quelque chose d’aussi simple que ceci :
<?php
/**
* Plugin Name: Acme Plugin
* Plugin URI: https://acmeplugins.com/acme
* Description: This is the plugin description.
* Version: 1.0.0
* Author: Acme Plugins Co.
* Author URI: https://acmeplugins.com/acme
* License: GPL-3.0+
* License URI: http://www.gnu.org/licenses/gpl-3.0.txt
*
* @since 1.0.0
* @package Acme
*/
namespace Acme;
defined( 'WPINC') || die;
// Include the custom autoloader.
require_once __DIR__. '/inc/autoload.php';
// Include action and filters.
require_once __DIR__. '/inc/actions.php';
require_once __DIR__. '/inc/filters.php';
Encore une fois, cela suppose que vous appliquez les trois recommandations. Si ce n’est pas le cas, votre implémentation peut varier.
