Les normes de codage WordPress accolades, expressions régulières et balises PHP

Dans cette série, nous avons exploré en profondeur les normes de codage WordPress afin de les faire connaître, de les comprendre et de les appliquer de manière pratique dans notre travail quotidien..

Si vous venez de rejoindre la série, nous avons jusqu'ici abordé les sujets suivants:

Conventions de dénomination et arguments de fonction
Citations simples et doubles citations
Indentation, utilisation de l'espace et espaces de fin

Dans cet article, nous allons continuer à nous appuyer sur le contenu de l'article précédent: Plus précisément, nous examinerons le style d'accolade, les expressions régulières et les nuances inhérentes à l'utilisation de balises PHP dans le contexte de construire des thèmes, des plugins et des applications WordPress.

Pourquoi le style est important

Tout au long de cette série, l’un des problèmes que nous avons maintes fois répété est que les normes de codage aident à rendre le code plus lisible et maintenable, et qu’elles devraient en définitive donner l’impression qu’un développeur a écrit le code..

Mais l’une des choses dont nous n’avons pas vraiment parlé est pourquoi style questions. Tout d’abord, cependant, cela soulève la question suivante: quelle est la différence entre les conventions de style et de codage??

Honnêtement, je pense que certains diraient qu'il n'y a pas de différence - en fait, ils diraient qu'ils sont synonymes. Je ne suis pas nécessairement d'accord Personnellement, j’ai toujours considéré que les normes de codage définir le style du code en cours d'écriture. Les normes de codage sont les conventions selon lesquelles nous appelons notre code.

Style de Brace

Ceci dit, reprenons notre conversation sur les conventions de codage en examinant comment les normes de codage WordPress définissent l’utilisation des accolades..

De manière générale, les règles sont simples:

Les blocs d'une seule ligne peuvent omettre des accolades
Les blocs multilignes doivent toujours inclure des accolades
Si vous avez trop de conditionnels multilignes, envisagez de les diviser en leurs propres fonctions afin de minimiser le blocage.

Ces principes sont souvent mieux illustrés par le code. Les deux premiers sont simples:

 // Exemples conditionnels sur une seule ligne if (condition1) do_work (); if (condition1) do_work (); sinon dont_do_work (); // Conditions multilignes if (condition1) do_work (); do_more_work ();  else dont_do_work (); sérieusement_be_lazy ();  // Boucles de lignes simples (true pour do / while, while, pour et foreach) while (condition1) dont_stop_believing (); // Boucles à ligne unique (true pour do / while, while, pour et foreach) while (condition1) dont_stop_believing (); hold_on_to_that_feeling ();

Rien de bien compliqué, c'est ça?

En fait, vous pouvez voir que j'ai utilisé des méthodes dans les blocs ci-dessus. C’est ce qui nous amène à notre prochain principe: si vous avez un corps trop compliqué dans votre conditionnel, il sera probablement utile de modifier le conditionnel pour en faciliter la lecture..

Regardons un exemple.

Avant

Dans cet exemple, nous allons parcourir les métadonnées de l'utilisateur actuel et, si la clé méta de l'utilisateur actuel a la sous-chaîne "destroy:", nous supprimerons la clé méta de cet utilisateur..

Notez dans cet exemple que tout ce travail est fait de manière conditionnelle, dans un pour chaque boucle, puis dans un autre conditionnel.

 // Si condition1 est vraie… if (condition1) //… alors récupère les métadonnées de l'utilisateur actuel foreach (get_user_meta (wp_get_current_user () -)) sous la forme $ meta_key => $ meta_value) // Si l'utilisateur a un ensemble de valeurs de destruction, supprimez-le. Cela signifie qu'ils ont choisi de ne pas supprimer un utilisateur. if (strstr ($ meta_key, 'destroy:')) delete_user_meta (wp_get_current_user () -> ID, $ meta_key);

Beaucoup de code imbriqué, à droite?

Après

Cela peut être modifié de différentes manières. En fait, certains développeurs iront jusqu'à prendre chaque bloc et à l'abréger dans sa propre méthode - il n'y a rien de mal à cela, que ce soit.

Mais pour démontrer ce point, nous ne fournirons qu'un niveau d'abstraction: nous allons prendre la boucle et le conditionnel interne, le déplacer vers une fonction qui accepte un utilisateur, puis exécuter l'action d'origine..

 // Si condition1 est vraie… if (condition1) utilisateur_processus (wp_get_current_user ());  function process_user ($ user) // Récupère les données de méteta de l'utilisateur actuel pour chaque utilisateur (get_user_meta ($ user-> ID) sous la forme $ meta_key => $ meta_value) // Si l'utilisateur a une valeur de destruction définie, supprimez-le. . Cela signifie qu'ils ont choisi de ne pas supprimer un utilisateur. if (strstr ($ meta_key, 'destroy:')) delete_user_meta ($ user-> ID, $ meta_key);

Comme je l'ai dit, il s'agit d'un exemple relativement simple, mais le point essentiel est le suivant: déplacer un grand bloc de code dans sa propre fonction spécialisée peut grandement contribuer à la refactorisation du conditionnel afin qu'il soit plus facile à lire..

Expressions régulières

À ce stade, nous allons changer un peu de sujet et parler brièvement d'expressions régulières. Si vous n'êtes pas familier avec les expressions régulières, sachez simplement qu'elles constituent un moyen puissant d'effectuer la correspondance de caractères ou de chaînes. Vous pouvez lire beaucoup plus à leur sujet sur Wikipedia.

Au cours de votre carrière dans le développement de WordPress, vous risquez de les rencontrer - soit dans le code source principal, le code du thème ou du plug-in, soit même en ayant besoin d'exécuter une action dans votre propre projet..

Heureusement, PHP offre des fonctions très simples et très puissantes pour utiliser des expressions régulières dans votre code. cependant, il y a des utilisations appropriées et inappropriées quand il s'agit de travailler avec eux dans WordPress.

Voici les règles générales:

Utilisez le preg fonctions offertes par PHP
Ne pas utiliser le \ e commutateur offert par PHP - utilisation preg_replace_callback au lieu.

Pour ceux qui sont curieux, un certain nombre de fonctions sont disponibles.

Par exemple, je vous recommande de vous familiariser avec:

preg_replace
preg_match
preg_match_all

finalement, preg_replace_callback est un moyen d'appeler une fonction lorsqu'une expression régulière a trouvé une correspondance.

De toute évidence, les règles relatives aux expressions régulières dans WordPress sont simples - il s’agit plus de connaître les fonctions que vous devrait utiliser et ce que vous ne devriez pas utiliser, et comment les utiliser dans votre travail quotidien.

Tags PHP

La dernière chose à couvrir dans cet article est l'importance de l'utilisation des balises PHP dans les fichiers PHP qui constituent votre projet. Heureusement, il existe une règle très simple pour cette situation particulière:

Ne jamais utiliser des balises PHP abrégées

Tout d’abord, cela signifie que vous ne devriez jamais ouvrir un fichier ou une déclaration PHP en ligne avec ou avec . Naturellement, toutes les déclarations PHP en ligne doivent toujours se terminer par ?> balise de fermeture.

 Maintenant, ce sujet suivant est un peu un écart par rapport aux normes de codage, du moins au moment d'écrire ces lignes, il devient de plus en plus courant de laisser la balise de terminaison au bas du fichier. si et seulement si la première ligne du fichier en question est une ouverture  étiquette.
 Plus précisément, cela est plus courant dans le contexte des plugins que dans les thèmes, et voici pourquoi: PHP est un moyen d'intégrer du code côté serveur dans le balisage frontal. En tant que tel, il nécessite à la fois une balise ouvrante et une balise fermante pour que l’interprète sache analyser le code..
 Mais si vous écrivez un plugin ou un fichier d’application 100% PHP, il n’est pas nécessaire d’ajouter une balise de fin à la fin du fichier. L'analyseur sera capable de le détecter lui-même, et si vous faire inclure une balise de terminaison, alors vous pouvez éventuellement avoir des espaces à la fin du fichier qui peuvent causer toutes sortes de problèmes lorsque vient le temps d'activer le plugin.
 Donc, en plus de la norme de codage définie ci-dessus, j'aimerais également ajouter:
  Évitez d'ajouter une balise PHP de terminaison dans des fichiers PHP purs.
 
 
 Conclusion
 Alors que nous abordons la dernière étape de l’examen des normes de codage WordPress, nous allons commencer à nous concentrer sur de plus petites choses, telles que les opérateurs ternaires et les conditions de Yoda; Cependant, nous examinerons également les aspects les plus précis de l'exécution de requêtes SQL en ligne et les règles importantes à cet égard..
 Si vous n'êtes pas déjà au courant de la série, le moment est venu de relire ce que nous avons couvert jusqu'à présent, car cela déterminera la direction que nous prendrons dans la prochaine série d'articles..



		
			
	   
	




Code