Lorsqu'il s'agit d'écrire une série de billets de blog, l'un des aspects les plus difficiles en tant que lecteur est de suivre chaque message publié..
Même si vous parvenez à suivre le rythme, les messages dépassant 1 000 mots, en particulier ceux qui incluent du code, peuvent prendre du temps que beaucoup d’entre nous n’ont pas, surtout quand il s’agit de jongler avec nos vies professionnelle, personnelle et familiale passe-temps et autres.
Donc, afin de m'assurer que les informations présentées tout au long de cette série sont toujours présentées de manière compréhensible, j'ai pensé essayer de résumer l'ensemble de la série. De cette façon, ceux qui ont manqué un article ou qui n’ont pas eu le temps de s’asseoir et qui ont lu chaque article peuvent quand même comprendre l’essentiel de chaque point mentionné dans les articles..
Cela dit, examinons tout ce que nous avons couvert lors de la révision des normes de codage WordPress..
De manière générale, le but de toute cette série est de contribuer à éclaircir les normes de codage WordPress afin que ceux qui n'en ont pas entendu parler, ceux qui ne les connaissent pas ou ceux qui ne les ont pas suivies soient mieux équipés pour écrire Thèmes, plugins et applications WordPress.
Pour ce faire, nous avons analysé en profondeur différents aspects des normes de codage dans six articles différents qui mettent en évidence les principes, les meilleures pratiques et les mesures à éviter..
Ci-dessous, nous avons résumé chacun des articles ainsi que les points centraux qui méritent d’être mentionnés pour le sujet en question. Bien sûr, si vous souhaitez plus d'informations, vous pouvez revenir à l'article de la série (lié en haut de cet article) pour le lire en entier..
Lorsque vous travaillez avec des classes, des fonctions, des variables, des attributs ou des arguments, les conventions de dénomination devraient aider à expliquer le but qu'elles servent..
Par exemple, les classes sont généralement des noms et les noms de fonctions sont normalement des verbes. En fin de compte, il s'agit de s'assurer que le code est lisible et maintenable.
Directement des normes de codage:
Ne pas abréger les noms de variables de manière non nécessaire. laisser le code sans ambiguïté et auto-documenté.
Mais ce principe particulier mérite d'être suivi indépendamment où vous travaillez dans le code.
Rappelez-vous que lorsqu'il s'agit de passer des arguments de fonction, il est important de se rappeler que si un nom de fonction décrit l'action qu'il effectue dans le contexte de la classe, alors l'argument doit représenter le fonctionnement réel de la fonction..
Préférez les valeurs de chaîne à juste
vrai
etfaux
en appelant des fonctions.
Cela signifie que les arguments de la fonction doivent être des valeurs claires - chaînes ou nombres -, car les valeurs booléennes sont souvent peu claires et n'indiquent pas nécessairement quelle action la fonction effectuera..
Quand il s’agit de travailler avec des chaînes dans WordPress, il s’agit généralement de s’intégrer aux nuances de la manipulation des chaînes PHP. En tant que tel, dans cet article, nous avons examiné comment PHP traite les guillemets (simples et doubles) et comment cela affecte notre développement WordPress..
Le moyen le plus simple de définir une chaîne en PHP consiste à l'envelopper de guillemets simples (c'est-à-dire du caractère ')..
Comme avec la plupart des langages de programmation, il sont façons d'échapper aux caractères afin que vous puissiez écrire un littéral de chaîne. Par exemple, si vous voulez écrire: "Les chaînes en PHP sont faciles", sous forme de chaîne, vous pouvez procéder comme suit:
"Les chaînes en PHP sont faciles."
Les barres obliques inverses demanderont à PHP d'écrire le guillemet simple plutôt que de terminer la chaîne. La deuxième chose à noter est que si vous avez une variable, il sera ne pas remplacé lorsque cité entre guillemets.
Les guillemets doubles fonctionnent un peu différemment dans PHP. Plus précisément:
Si la chaîne est placée entre guillemets ("), PHP interprétera davantage de séquences d'échappement pour les caractères spéciaux..
Cela signifie que si vous incorporez une variable dans une chaîne PHP à double guillemet, alors la variable sera interprétée et sa valeur sera insérée à la place de la variable avant de l'afficher à l'écran..
Comme une grande partie du travail effectué dans WordPress inclut également la rédaction de balises dans une chaîne PHP, il est préférable de placer ces chaînes entre guillemets simples afin que les attributs de l'élément HTML puissent être placés entre guillemets.
Mais il est parfois préférable d'utiliser des guillemets doubles notamment quand vous avez besoin d'évaluer une variable.
Le meilleur conseil que nous puissions offrir ici est de savoir comment fonctionnent les guillemets simples et les guillemets doubles dans PHP, puis de les utiliser de manière appropriée en fonction de votre cas d'utilisation..
N'oubliez pas: les espaces blancs améliorent la lisibilité du code et, en tant que développeur, l'un de nos principaux objectifs doit être de nous assurer que le code que nous écrivons ne respecte pas seulement une norme prédéfinie, mais qu'il s'adresse également aux autres développeurs afin de faciliter maintenabilité.
En ce qui concerne l'indentation, il n'y a rien de vraiment nouveau, surtout si vous connaissez les langages de type C. La plupart du temps, vous indenterez chaque fois que vous commencerez un nouveau bloc.
Notez que les normes de codage faire avoir des règles sur les tabulations et les espaces:
Votre mise en retrait doit toujours refléter la structure logique. Utilisation vrais onglets et pas d'espaces, car cela permet le plus de flexibilité entre les clients.
Ceci est particulièrement utile dans la communauté open source.
Les espaces doivent être placés aux endroits suivants:
||
, &&
, et !
)<
, >
, ==
, ===
, etc.)=
)C'est l'une des conventions les plus simples à suivre. Honnêtement, il y a de fortes chances pour que votre IDE ou l'éditeur de votre choix intègre cette fonctionnalité, ou qu'un plugin soit disponible pour vous permettre de le faire automatiquement..
Sinon, vous devriez pouvoir activer la possibilité de voir les tabulations, les espaces, les retours à la ligne, etc., de manière à pouvoir facilement identifier où les espaces de fuite sont. Et quand vous les voyez, éliminez-les.
Dans cette section, nous avons examiné pourquoi le style est important. Nous avons également défini exactement comment les normes et conventions de codage définissent Comment nous appelons notre code.
De manière générale, les règles sont simples:
Celles-ci sont particulièrement courantes si vous venez d'autres langages de style C; cependant, tout comme WordPress a des nuances subtiles que d’autres langues n’a pas, il convient de les souligner ici.
PHP offre une variété de façons de travailler avec des expressions régulières, bien que WordPress recommande de n'utiliser qu'une poignée des fonctions disponibles..
Les règles d'utilisation des expressions régulières en PHP dans WordPress sont les suivantes:
preg
fonctions offertes par PHP\ e
commutateur offert par PHP - utilisation preg_replace_callback
au lieu.Plus précisément, je vous recommande de vous familiariser avec les fonctions suivantes:
preg_replace
preg_match
preg_match_all
De plus, notez que preg_replace_callback est un moyen d'appeler une fonction lorsqu'une expression régulière a trouvé une correspondance..
Il existe une règle très simple d'utilisation des balises PHP dans le développement WordPress:
Cela signifie que vous ne devriez jamais ouvrir un fichier ou une déclaration PHP en ligne avec ou avec
=
. Naturellement, toutes les instructions PHP en ligne doivent être terminées avec ?>
balise de fermeture.
En plus de la norme de codage définie ci-dessus, j'aimerais également ajouter:
La raison en était mentionnée textuellement dans l'article associé:
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 appeler toutes sortes de problèmes lorsque vient le temps d'activer le plugin.
En matière d’écriture de code WordPress, les normes de codage stipulent que nous devons viser la lisibilité:
En général, la lisibilité est plus importante que l'habileté ou la brièveté.
Certains développeurs considèrent que l'opérateur ternaire est un peu en désaccord avec ce principe particulier, en particulier parce que c'est encore une autre façon d'écrire un sinon
déclaration. Même encore, l'opérateur ternaire est une option viable quand il s'agit d'écrire des conditionnels simples et est indiqué dans les normes de codage WordPress.
Tout d’abord, pour ceux qui ne sont pas familiers, l’opérateur ternaire est une manière simplifiée d’écrire un sinon
déclaration conditionnelle. Il est généralement utilisé seulement quand le conditionnel est de la forme la plus simple et seulement quand il y a un seul si
et un seul autre
bloc.
$ uses_gasoline = 'hybride' == $ car_type? faux vrai; echo $ uses_gasoline;
Une chose importante à noter: l'opérateur ternaire teste vrai (plutôt que faux, évidemment).
Les conditions Yoda font référence à l'inversion des comparaisons de variable à valeur effectuée lors de l'écriture de code WordPress. Nous cela, selon les normes de codage, parce que:
Dans l'exemple ci-dessus, si vous omettez un signe égal (admettez-le, cela arrive même aux plus aguerris), vous obtiendrez une erreur d'analyse, car vous ne pouvez pas affecter une constante telle que
vrai
. Si la déclaration était l'inverse($ the_force = true)
, la cession serait parfaitement valide, retournant1
, provoquant la déclaration si évaluervrai
, et vous pourriez être chasser ce bug pendant un certain temps.
Bien sûr, c'est discutable, mais ça est une partie de la norme et vous sont aller voir cela utilisé par le biais de WordPress, thèmes, plugins, articles, etc..
Donc, en bref, si l’API n’atteint pas ce dont vous avez besoin, alors $ wpdb
peut être votre meilleure option, mais je vous recommande de ne l'utiliser que si vous avez épuisé le reste de vos options.
Dans WordPress, un certain nombre d'API nous permettent de concevoir nos propres requêtes sans avoir à écrire du code SQL. Certaines de ces API incluent:
WP_Query
WP_User_Query
get_post_meta
get_comment_meta
get_user_meta
Il est important de vous familiariser avec les offres de l'API afin de savoir s'il existe ou non une fonction ou un objet disponible à utiliser avant de se lancer directement dans l'écriture de vos propres requêtes..
Les API ne peuvent pas prédire tout cas dans lesquels nous devons écrire nos requêtes de base de données. Et dans ces situations, WordPress fournit un objet qui nous permet d’interagir directement avec la base de données: $ wpdb
.
Cela nous permet de:
SÉLECTIONNER
variables, lignes, colonnes et résultats génériquesINSÉRER
rangéesMETTRE À JOUR
lignes existantesEt nous permettre de récupérer les données dans un format que nous aimerions le plus travailler: un tableau, un objet ou une valeur unique (dans certains cas), et nous permet même de nous protéger par injection SQL.
Mais rappelles-toi:
Si vous devez toucher à la base de données, contactez certains développeurs en postant un message sur la liste de diffusion wp-hackers. Ils souhaiteront peut-être envisager de créer une fonction pour la prochaine version de WordPress afin de couvrir les fonctionnalités souhaitées..
Comme je l'ai mentionné plus tôt, il peut être difficile de suivre une série d'articles, notamment ceux qui impliquent le code. À cette fin, je souhaitais expérimenter en fournissant un résumé de la série qui donne encore assez d’informations à ceux qui n’ont pas eu la chance de suivre l’ensemble de la série, mais qui sont toujours intéressés par les sujets abordés..
Donc, si vous aimez cette stratégie ou ce type d'article, faites-le-moi savoir et nous pourrons peut-être continuer à le faire pour d'autres séries; sinon, pas de mal, pas de faute - je vais bien de toute façon.
Quoi qu’il en soit, j’espère que la série a permis d’expliquer un certain nombre de domaines des normes de codage WordPress que vous avez déjà oubliés, mal compris ou dont vous n’avez pas complètement parlé avant de lire ces articles.