Utilisation des PSR (par rapport aux normes de codage WordPress)

À ce stade, je ne sais pas combien d’articles j’ai écrits sur l’importance des normes de codage WordPress (suffisamment pour les lier ici, ici et ici, je suppose, ce qui compte pour quelque chose).

Mais après avoir fait suffisamment de projets pour des clients et travaillé avec des développeurs qui sont beaucoup plus intelligents et familiarisés avec les outils avancés que moi, je suis à un endroit où je choisis de commencer à utiliser les PSR dans le développement de WordPress WordPress.

Ah le drame, non ?

Sérieusement. Il y a des raisons à cela, et il y a des moments où je pense que les normes de codage WordPress devraient toujours être utilisées, mais je suis rapidement de plus en plus convaincu que la construction de tout projet moderne sur WordPress devrait utiliser des outils PHP plus modernes (que je Je mentionnerai brièvement plus tard).

Utilisation des PSR dans le développement WordPress

Des messages comme celui-ci donnent souvent un aperçu d’un débat ou d’une réponse dramatique au sein de WordPress, ce qui n’est pas mon intention ni quelque chose que je pense même nécessaire. Pour être honnête, je connais un bon nombre d’ autres développeurs qui ont tous fait cela il y a longtemps, en ont parlé, ont avancé et ont continué à avoir du succès à la fois dans leur entreprise et dans leurs projets de loisirs.

Mais étant donné que j’ai tellement parlé de l’un par rapport à l’autre, j’ai pensé qu’il valait la peine de partager mon point de vue sur les raisons pour lesquelles j’opte pour ce changement maintenant et sur la justification qui le sous-tend.

1 Parité avec la communauté PHP

Au cours de la dernière année environ, et vraiment au cours des derniers mois de cette année seulement, je me suis habitué à :

• des amis développeurs orientés PHP plus expérimentés qui approuvent les outils qui s’attendent à ce que les PSR soient adoptés,
• l’utilisation de //@codingStandardsIgnoreStart et //@codingStandardsIgnoreEnd dans mon code,
• des ensembles de règles personnalisés pour mes projets en fonction des environnements dans lesquels ils sont déployés,
• et plus.

En fin de compte, il s’agit de vouloir maintenir la parité (ou un peu) avec la plus grande communauté PHP tout en écrivant du code lisible et basé sur des normes au-dessus de WordPress. Et j’aimerais aussi utiliser d’autres outils et des versions plus récentes d’outils existants (dont je parlerai plus tard dans cet article).

2 Problèmes avec les environnements modernes

Au moment de la rédaction de cet article, PHP CodeSniffer (nécessaire pour exécuter les normes de codage WordPress) est à la version 3.0.2. Cependant, il existe des problèmes de compatibilité avec PHPCS et avec les normes de codage WordPress. Plus précisément :

La nouvelle version de PHP CodeSniffer a quelques fonctionnalités intéressantes, mais introduit des changements de rupture qui signifient que les normes de codage WordPress ne sont pas compatibles.

Pour être clair (et en raison de la nature du logiciel), c’est une question de temps avant qu’il ne soit corrigé. Mais si vous travaillez sur une base de code et que vous utilisez Composer et les normes de codage WordPress, vous devrez définir explicitement la version de PHP CodeSniffer plutôt que la version la plus récente actuellement.

De plus, j’ai rencontré des problèmes avec des clients où le fait que je n’adopte pas les PSR dans le développement de WordPress a entraîné un comportement étrange lors du déploiement de code. On pourrait peut-être faire valoir qu’ils devraient ajuster l’environnement, mais s’ils s’efforcent de mettre les outils les plus modernes à la disposition des personnes qui les utilisent, pourquoi régresser ?

3 Compatibilité avec les outils modernes

Enfin, il existe un certain nombre d’outils modernes que je n’ai pas pu utiliser, et encore moins apprendre, à cause de ce qui est et de ce qui n’est pas pris en charge par la nature de la gestion des versions.

Par exemple, nous utilisions GrumPHP dans un projet récent qui prend en charge une variété d’outils, mais nous n’avons pas pu utiliser, disons, PHPMD en raison du manque d’adoption des PSR. En ce qui me concerne :

• Je veux continuellement améliorer mes compétences en tant que développeur (et, dans ce contexte, développeur PHP),
• le manque de support pour des outils plus modernes me met dans un schéma d’attente que je n’aurais pas connu autrement,
• Je veux continuer à travailler avec WordPress mais le faire avec un flux de travail plus moderne

Et en ce moment, ne pas utiliser les PSR crée un fossé entre ce que fait le reste de la communauté PHP et ce que fait WordPress. J’aimerais donc avancer tout en continuant à travailler sur des projets en plus des logiciels que j’aime toujours utiliser.

Qu’en est-il des normes de codage WordPress

Alors, qu’est-ce que cela signifie à propos des normes de codage WordPress et des publications précédentes ? Rien, vraiment. La façon dont je le vois: Les normes de codage WordPress doivent être utilisées chaque fois que vous travaillez sur WordPress Core ou quelque chose qui va y être étroitement intégré.

Mais si vous travaillez sur quelque chose qui repose sur WordPress ou sur quelque chose qui utilise WordPress comme base et que vous pouvez utiliser les PSR dans le développement WordPress avec des outils qui peuvent aider à augmenter la qualité de la base de code que vous construisez.

Donc, du moins pour l’instant, c’est la perspective que je vais adopter. J’ai hâte de voir comment ça se passe dans les prochains mois. Et, comme pour tout ce que j’ai partagé, je partagerai les aspects de la réalisation de ce changement.