Share
Dans cette série, nous explorons de manière approfondie les normes de codage WordPress - en particulier les normes de codage PHP - afin d’évangéliser et de comprendre comment un code WordPress de qualité devrait être écrit..
Bien que cela soit documenté dans le manuel du développeur WordPress, je pense qu'il y a quelque chose à dire pour comprendre la raison d'être de Pourquoi certaines choses sont comme ça.
Rappelez-vous: notre objectif ultime est de nous assurer que nous rédigeons un code conforme aux normes de codage, de manière à ce que nous-mêmes, ainsi que les autres développeurs, soyons en mesure de lire, comprendre et gérer plus facilement le code des thèmes, plug-ins et applications générés sur WordPress.
Dans cet article, nous allons examiner comment gérer les conventions de dénomination et les arguments de fonction..
Avant de passer au moindre détail sur les points décrits dans les normes de codage, il est important de comprendre le rôle que jouent les conventions de dénomination dans la rédaction de code, quelle que soit la plate-forme avec laquelle vous travaillez..
En fin de compte, les conventions de dénomination - qu’elles s’agissent de classes, de fonctions, de variables, d’attributs ou d’arguments - devraient aider à expliquer le but qu’elles servent..
J'entends par là que les noms de classe doivent généralement être des noms, que les fonctions doivent être des verbes et que des variables, des attributs et des arguments doivent expliquer leur fonction dans le contexte de la classe ou de la fonction dans laquelle ils doivent être définis. Il s'agit de rendre le code aussi lisible que possible.
Tout comme le stipulent les 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é.
C'est une bonne règle de base indépendamment de quelle partie du code il est sur lequel vous travaillez.
Quand il s'agit de travailler avec WordPress, vous ne rencontrerez probablement pas de cours à moins de faire l'une des deux choses suivantes:
Si vous travaillez simplement sur le thème, vous travaillerez probablement avec un ensemble de fonctions - nous en parlerons dans un instant..
Mais pour ceux qui travaillent avec des plugins ou leurs propres bibliothèques, il est important de se rappeler que les classes doivent être des noms - elles doivent représenter le but qu'elles encapsulent et idéalement, elles doivent faire une chose et bien la faire..
Par exemple, si vous avez une classe appelée Local_File_Operations alors il peut être responsable de la lecture et de l'écriture des fichiers. Il ne devrait pas être responsable de la lecture et de l’écriture de fichiers, ni de la récupération de fichiers distants, par exemple..
Selon les normes de codage WordPress, les classes doivent respecter les conventions suivantes:
Simple, droit?
Concrètement, cela ressemblerait à ceci:
Accentsconagua
classe Local_File_Operations classe Remote_File_Operations classe HTTP_Request classe SQL_Manager Pour réitérer: les classes devraient également être des noms et devraient décrire le seul but qu'elles servent.
Comme mentionné précédemment, si les classes sont des noms qui représentent idéalement une seule idée ou un seul objectif, leurs méthodes doivent être les actions qu’elles sont capables de réaliser. En tant que tels, ils doivent être des verbes - ils doivent indiquer quelle action sera prise chaque fois qu'ils sont appelés.
De plus, les arguments qu’ils acceptent doivent également entrer en compte dans le nom de la fonction. Par exemple, si une fonction est chargée d’ouvrir un fichier, son paramètre doit alors être un nom de fichier. Puisque notre objectif doit rendre la lecture du code aussi facile que possible, vous devez alors lire quelque chose du type "demandez au gestionnaire de fichiers local de lire le fichier portant le nom de fichier suivant".
Dans le code, cela peut ressembler à quelque chose comme ça:
// La classe de définition de classe Local_File_Manager fonction publique open_file ($ filename) // implémentation de la fonction // // comment nous utiliserions ce code $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); Bien sûr, cela ne couvre toujours pas Comment les fonctions doivent être écrites dans le contexte du développement WordPress. Les normes de codage stipulent:
Utilisez des lettres minuscules dans les noms de variables, d’actions et de fonctions (jamais).
affaire de chameau). Séparez les mots via des traits de soulignement. Ne pas abréger les noms de variables de manière non nécessaire. laisser le code sans ambiguïté et auto-documenté.
La première partie de la convention est assez facile à comprendre. Cependant, je pense que les développeurs ont tendance à prendre des raccourcis quand ils le peuvent. "Ah," pensons-nous "$ str est logique ici, et numéro $ avoir un sens ici. "
Bien sûr, il y a toujours pire: certains développeurs ont recours à des caractères uniques pour leurs noms de variables (ce qui n'est généralement acceptable que dans les boucles).
Tout comme le stipulent les normes de codage: Ne pas abréger les noms de variables un-nécessairement. Laissez le code être sans ambiguïté et auto-documenté.
La vérité est que le code ne peut pas être ambigu. Après tout, c'est pourquoi on appelle ça du code, non? C'est pourquoi je pense que les commentaires de code doivent être utilisés généreusement.
Quoi qu’il en soit, l’essentiel est de mettre en minuscule les noms de vos méthodes, d’éviter toute casse de chameau, de les séparer par espacement et d’être aussi précis que possible lorsque vous nommez vos variables..
Les noms de variables ne sont en réalité pas très différents des noms de fonctions, à part qu’ils représentent une valeur unique ou une référence à un objet particulier. Les conventions de dénomination suivent toujours ce que vous attendez:
Une autre convention utilisée par certains développeurs est la notation hongroise, où le type de valeur stocké par la variable est préfixé devant la variable..
Par exemple:
$ str_firstname $ i_tax ou $ num_tax $ arr_range Honnêtement, les normes de codage ne disent rien à ce sujet. D'un côté, je pense que cela crée un code plus propre dans l'ensemble du code, mais de nombreux développeurs n'aiment pas la notation hongroise..
Comme les conventions de codage ne disent rien à leur sujet, j’hésite à les recommander car je veux rester aussi proche que possible des normes. En tant que tel, je dois recommander qu'il soit préférable de respecter les normes de codage.
Afin de rester cohérent avec le thème de rendre notre code aussi lisible et auto-documenté que possible, il est logique de tirer cela du code source jusqu'aux fichiers que nous allons créer dans notre thème, plugin ou. application.
Selon les normes de codage:
Les fichiers doivent être nommés de manière descriptive en minuscules. Les traits d'union doivent séparer les mots.
Conformément à notre exemple précédent, supposons que nous travaillions avec Local_File_Operations alors le fichier serait nommé class-local-file-operations.php.
Assez facile.
Ensuite, si vous travaillez sur un plugin appelé Instagram_Foo alors le fichier devrait être nommé instagram-foo.php; Toutefois, il convient de noter que si vous utilisez certaines méthodes avancées pour développer vos plugins, telles que conserver le fichier de classe du plugin dans son propre fichier, puis le charger à l'aide d'un autre fichier, votre structure de fichier peut être:
classe-instagram-foo.phpinstagram-foo.phpOù instagram-foo.php est responsable du chargement du classe-instagram-foo.php. Bien sûr, cela n'a de sens que si vous utilisez la POO lors de l'écriture de vos plugins WordPress.
Lorsqu’il s’agit de passer des arguments de fonction, il est important de se rappeler que si les noms de fonction décrivent les actions entreprises par la classe, alors l’argument doit représenter le fonctionnement réel de la fonction..
Des normes de codage:
Préférez les valeurs de chaîne à juste
vraietfauxen appelant des fonctions.
Comme les valeurs booléennes peuvent ne pas être claires lors du passage de valeurs dans une fonction, il est difficile de déterminer exactement ce que fait la fonction..
Par exemple, utilisons l’exemple ci-dessus d’une manière légèrement différente:
// La classe de définition de classe Local_File_Manager fonction publique manage_file ($ filename, true) if (true) // ouvre le fichier else // supprime le fichier // comment nous utiliserions ce code $ file_manager = new Local_File_Manager (); $ file_manager-> manage_file ('foo.txt', true); Est plus difficile à comprendre que, disons, quelque chose comme ceci:
// La classe de définition de classe Local_File_Manager function publique open_file ($ filename) // ouvre le fichier function publique delete_file ($ filename) // supprime le fichier // Comment utiliserions-nous ce code $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); $ file_manager-> delete_file ('foo.txt'); De plus, rappelez-vous que les arguments passés dans les fonctions sont toujours des variables en eux-mêmes, ils sont donc soumis aux conventions de dénomination des variables que nous avons détaillées ci-dessus..
Nous avons examiné de manière approfondie les conventions de dénomination et les arguments de fonction dans les normes de codage. J'espère que cela a permis de fournir non seulement un guide sur la façon d'améliorer certains aspects de votre code WordPress, mais aussi d'expliquer la raison d'être de certaines pratiques..
Dans le prochain article, nous allons examiner la signification des guillemets simples et des guillemets doubles dans le contexte de l'utilisation de chaînes dans le développement WordPress..
Là est une différence dans la façon dont ils sont interprétés par PHP et il y a des conditions dans lesquelles vous devriez utiliser l'une sur l'autre et nous allons en parler dans le prochain article.
