Normes de codage de base via PSR-1

Hier, j’ai parlé brièvement d’une justification de l’utilisation des PSR par rapport aux normes de codage WordPress et du quand et pourquoi des deux. Mais cela ne veut pas dire que ce n’est pas sans points de confusion, surtout si vous débutez avec eux, n’est-ce pas ?

Par cela, je veux dire: supposons que vous travaillez avec les normes de codage WordPress depuis des années (parce que je peux comprendre) et maintenant il y a tout un nouvel ensemble de règles et de directives à suivre. Mais ce n’est pas comme une simple question de changer un espace blanc et de renommer des fichiers.

Il y a d’autres points à suivre, et chacun est décrit dans un numéro, littéralement (PSR-1, PSR-2, etc.), de la façon dont quelque chose devrait fonctionner.

Donc, en ce qui concerne uniquement les normes de codage de base décrites dans PSR-1, quels sont les domaines problématiques que nous pouvons rencontrer en tant que développeurs WordPress ?

Normes de codage de base (et effets secondaires)

Je n’ai pas l’intention de parcourir chacun des documents et de ressasser ce que nous pouvons déjà apprendre en les lisant simplement, mais je pense qu’il y a quelque chose à dire pour prendre quelque chose que beaucoup d’entre nous font ou expérimentent et voir comment cela pourrait changer à l’intérieur le contexte de WordPress.

Prenez les effets secondaires de la norme de codage de base (ou PSR-1 ), par exemple :

Un fichier DEVRAIT déclarer de nouveaux symboles (classes, fonctions, constantes, etc.) et ne provoquer aucun autre effet secondaire, ou il DEVRAIT exécuter une logique avec des effets secondaires, mais NE DEVRAIT PAS faire les deux.

L’expression "effets secondaires" signifie l’exécution d’une logique non directement liée à la déclaration de classes, de fonctions, de constantes, etc., simplement à partir de l’inclusion du fichier.

Personnellement, je trouve que la deuxième phrase est la clé pour comprendre et éviter autant que possible les effets secondaires dans notre code. Autrement dit, tout ce que nos classes font doit être autonome ou cohérent avec quelque chose qui a pu être injecté d’une manière ou d’une autre.

Quoi qu’il en soit, trouver un code qui introduit un effet secondaire et le nettoyer ne devrait pas être trop difficile. En fait, je vais me servir d’exemple.

Regardez ce morceau de code particulier :

Ce code provient directement de Toggle Admin Notices. Certes, c’est simple et le référentiel indique comment le modifier. Cela démontre néanmoins le point, non?

Quelle est la solution? Cela se présente sous la forme d’un chargement automatique (qui est également couvert dans PSR-4 ). Et si je devais le refactoriser, pour qu’il suive correctement PSR-1 ? Ensuite, une façon de le refactoriser peut ressembler à ceci :

Est-ce un bon exemple ? Probablement pas. Mais il ne suffit pas d’inclure des fichiers. L’inclusion de ces fichiers, c’est que ce fichier unique introduit une variété d’effets secondaires.

Cela signifie que ce seul fichier est responsable de faire bien plus que ces quatre lignes de code. Considérez-le comme incorporant tout ce que les autres fichiers implémentent. Cela devient plus complexe à ce moment-là.

Alors, prenez cette idée et déplacez-la dans un système beaucoup plus vaste et vous pouvez voir comment et pourquoi cela serait problématique.

Bien sûr, il existe également des moyens alternatifs. Et ceci n’est qu’un exemple. Autodérision aussi. Il ne s’agit pas tant de montrer une manière définitive de le faire, mais de commencer à semer des réflexions sur la façon dont nous concevons, planifions, construisons et intégrons des classes.

Qu’en est-il des vues ?

Quand il s’agit d’écrire des plugins, j’ai tendance à traiter ce que les utilisateurs verront comme des vues. Mais il semble y avoir un hic ici: il est considéré comme une mauvaise pratique d’inclure des fichiers car cela introduit des effets secondaires.

Nous ne voulons donc pas produire de logique dans nos classes, mais nous voulons également séparer la présentation de la logique métier.

Que devons-nous faire?

La torsion… est que nous allons utiliser la programmation orientée objet pour le faire. Nous allons concevoir une classe qui génère du HTML à l’aide du modèle PHP.

Cela a été couvert en profondeur par quelqu’un d’autre, et je recommande fortement de lire ce post particulier pour prendre l’idée des effets secondaires, les éviter et incorporer autant que possible des pratiques solides.

… Et les actifs et les fichiers associés ?

Je sais : l’idée de s’éloigner des effets secondaires (et encore moins de les identifier) ​​peut être bizarre au début, surtout quand on pense à certaines choses que nous avons faites depuis si longtemps.

Et cela peut soulever des questions telles que : l’inclusion de fichiers JavaScript ou de fichiers CSS est-elle incorrecte ? C’est probablement un sujet pour un autre post. Rappelez-vous, cependant, qu’il existe des fonctions API de base directement liées à cela, et elles peuvent faire partie d’une classe strictement responsable de cela.

Si le but d’une classe est de faire exactement cela et seulement cela et qu’elle utilise des fonctions API pour le faire, alors je dirais que c’est probablement correct.

Mais je m’égare là-dessus pour l’instant (et c’est peut-être un sujet pour les commentaires ou, encore une fois, un autre post).

Au lieu de cela, gardez vos cours légers et utiles. Ils doivent faire comme les états PSR-1 et éviter de faire des choses telles que "[déclarer] de nouvelles classes, fonctions, constantes, etc." et "[exécuter] une logique avec des effets secondaires".