Normes de codage pour WordPress [Guide]

La raison pour laquelle nous avons des normes de codage (pas seulement pour WordPress) est la suivante: créer un environnement familier pour les programmeurs travailler sur un projet. WordPress en particulier englobe une grande variété de produits. Du coeur même aux thèmes et plugins, il y a beaucoup de choses à regarder - et beaucoup de choses à mélanger à propos de.

Si tout le monde formate son code de la même manière, utilise des commentaires, utilise le même style de documentation, etc., travailler ensemble devient d'autant plus facile et la courbe d'apprentissage pour rejoindre un nouveau projet ne sera pas aussi abrupte..

Le besoin de cohésion dans WordPress est amplifié par l'état dans lequel se trouve la base de code. WordPress ne suit pas une approche stricte orientée objet et n'utilise pas de modèle MVC. Les projets qui suivent les directives OOP et MVC sans exception (comme Laravel) ont une cohérence et des pratiques exemplaires “cuit au four” en raison de leur structure.

WordPress est malheureusement mûr pour le codage de spaghettis, aka faire ce que tu veux. Les meilleures pratiques sont difficiles à appliquer simplement parce que les produits utilisant un code incorrect peuvent tout aussi bien fonctionner (à la surface).

En suivant les normes de codage WordPress, vous pouvez en apprendre un peu plus sur l’éthique de codage de WordPress et créer davantage de produits compatibles WordPress. montrer à la communauté que vous vous souciez et que vous vous disputez avec un code de haute qualité.

Plus sur Hongkiat.com:

10 pires cauchemars pour les développeurs Web
5 raisons pour lesquelles CSS pourrait être le langage le plus dur de tous
30 réactions courantes des programmeurs lorsque les choses tournent mal

Quelques notes sur les normes

Les normes ne définissent pas le bien et le mal. Vous pouvez être en désaccord avec une règle, par exemple, les accolades devraient toujours être utilisées, même si elles ne sont pas nécessaires. Le but des normes de codage WordPress n'est pas de décider si vous avez raison ou de vous tromper, c'est de décider comment cela devrait être fait dans WordPress.

Les normes ne sont pas à débattre. L’utilisation des normes n’est pas l’endroit idéal pour prendre position contre un style d’indentation que vous n’aimez pas. Si quelque chose est dans les normes de codage, faites-le ainsi. Les développeurs WordPress vont vous aimer pour cela! Cela dit, si vous n’êtes pas d’accord avec quelque chose, élevez la voix et faites-le savoir. Il est toujours possible de faire mieux, mais vous ne devriez changer votre style de codage que si les normes le permettent..

Cohérence par rapport à la rétention anale. Si vous êtes dans les derniers 10% de votre projet et que vous venez de découvrir que vous utilisiez une convention de dénomination incorrecte pour les classes, ne changez pas de niveau. Selon mon opinion personnelle, je préférerais lire quelque chose qui est toujours incorrect que quelque chose qui est parfois correct et parfois non. Vous pouvez toujours écrire un script pour changer les choses en une fois ou lire votre code à la fin..

Suivre les normes est difficile! Placer une accolade sur la même ligne que la fonction à la place d'une ligne ci-dessous est assez facile, même si vous êtes habitué à appuyer sur Entrée auparavant. Cependant, lorsque vous devez penser à 100 petites règles, l'ensemble du processus devient un peu sujet aux erreurs. Malgré ma position ferme sur le respect des normes, je suis aussi coupable que quiconque de faire des erreurs. En fin de journée, une indentation incorrecte n'est pas un péché irrévocable. Faites de votre mieux pour suivre toutes les règles, vous apprendrez tout dans le temps.

Normes de codage WordPress

WordPress propose actuellement quatre guides, un pour chaque langue principale utilisée: PHP, HTML, Javascript et CSS. Ils font partie d'un ensemble de connaissances plus vaste, le Core Contributor Handbook. Tout parcourir prendrait un certain temps et j'ai donc mis en évidence des extraits des quatre langues que je vois souvent se tromper.

PHP

PHP est la langue principale de WordPress et est un langage assez typé qui le rend mûr pour la réglementation.

Styles Brace

Les accolades de départ doivent toujours être placées à la fin des lignes. Les déclarations associées doivent être placées sur la même ligne que l’accolade de fermeture précédente. Ceci est mieux démontré avec un exemple de code:

if (condition) // Faire quelque chose elseif (condition) // Faire quelque chose else // Faire quelque chose

Utilisation généreuse de l'espace

Je ne suis pas un fan de code compressé (j'ai une mauvaise vue), c'est donc un système que j'aime particulièrement appliquer. Mettre des espaces après des virgules, et des deux côtés de logique, Comparaison, chaîne et opérateurs d'affectation, après si, sinon, pour, pour chaque et commutateur déclarations et ainsi de suite.

Il est plus facile de dire où les espaces ne doivent pas être ajoutés! Les seules fois où vous ne devriez pas ajouter d'espaces, c'est quand dactylographie ou référençant des tableaux.

Une exception plutôt déroutante est constituée par les tableaux où la clé de tableau est une variable, dans ce cas, utilisez un espace. Cet exemple devrait clarifier ceci:

function ma_fonction ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (entier) $ key_1; $ final_array [0] = 'this'; $ final_array [$ key_1] = 'est'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example';  return $ final_array;

Conventions de nommage

Celui-ci peut être difficile, surtout si vous venez d'environnements différents. En un mot:

Noms de variables devrait être tout en minuscule, mots séparés par des traits de soulignement
Noms de classe devrait utiliser mots en majuscules séparés par des underscores. Les acronymes devrait être tout majuscule
Constantes devrait être tout en majuscule, sous le signe de soulignement
Noms de fichiers devrait être tout en minuscule, séparés par des tirets

Yoda Conditions

En écrivant les conditions dans le sens inverse, vous éviterez les erreurs d’analyse. Ça a l'air un peu bizarre mais c'est un meilleur code.

if ('Daniel' === $ name) echo 'Rédigez un article, vous voulez';

HTML

HTML n'a pas beaucoup de règles associées, je pourrais en créer beaucoup pour rendre les choses plus modulaires. Il n’ya que cinq règles à connaître lors de l’écriture HTML:

Votre code doit être validé par le validateur W3C.
Les balises HTML à fermeture automatique doivent avoir exactement un espace avant la barre oblique (je la déteste personnellement, mais c’est une spécification W3C, pas seulement une bête noire de WordPress)
Les attributs et les balises doivent être en minuscules. La seule exception concerne les valeurs d'attribut destinées à la consommation humaine, auquel cas elles doivent être typées naturellement.
Tous les attributs doivent avoir une valeur et doivent être cités (écriture). n'est pas correcte)
L'indentation doit être réalisée à l'aide d'onglets et suivre la structure logique..

CSS

CSS est un autre langage faiblement typé, il y a donc beaucoup de travail à faire ici aussi. Malgré tout, les standards sont assez faciles pour les codeurs.

Sélecteurs

Les sélecteurs doivent être aussi qualifiés que nécessaire, lisibles par l'homme, être en minuscule avec des mots séparés par des tirets, et les sélecteurs d'attributs doivent utiliser des guillemets. Voici un exemple concis:

input [type = "text"], input [type = "mot de passe"], .name-field background: # f1f1f1;

Commande de propriété

Les normes reconnaissent la nécessité d'un espace personnel ici, car elles ne prescrivent pas d'ordre spécifique pour les règles CSS. Ce qu'ils faire dire est que vous devriez suivre une structure sémantique logique. Grouper les propriétés par leurs relations ou les grouper par ordre alphabétique, juste ne les écris pas au hasard.

La principale cause d’aléatoire est le “oh j'ai aussi besoin d'ajouter une marge” et ensuite procéder pour l'ajouter au bas. Prenez les 0,3 secondes supplémentaires et ajoutez la règle à la place logique.

Afficher
Positionnement
Modèle de boîte
Couleurs et typographie
Autre

.profile-modal display: block; position: absolue; à gauche: 100px; en haut: 90 px; arrière-plan: # ff9900; couleur: #fff;

Formatage de la valeur

C'est un endroit où je déteste particulièrement voir les incohérences. Si vous ne suivez pas les directives, c'est toujours mieux que de voir parfois un espace avant la valeur; parfois en sténo, parfois non; parfois en utilisant des unités sur des valeurs 0, parfois pas, etc..

Le formatage des valeurs est assez complexe mais cela vient naturellement avec un peu de pratique. Consultez le guide exact du Codex pour formater vos valeurs.

Javascript

D'après mon expérience, Javascript est le plus enclin à aller partout. Alors que de nombreux développeurs connaissent une quantité considérable de Javascript, il a été appris progressivement, après coup, pour HTML, CSS et PHP. Lorsque vous débutez avec une nouvelle langue, vous faites beaucoup plus d'erreurs et si ces erreurs ne causent pas d'erreurs fatales, elles peuvent s'enraciner en vous..

Dans de nombreux cas, les normes font référence à une limite de ligne ou à un état “si une ligne n'est pas trop longue”. Ceci fait référence au Guide de style jQuery qui impose une Limite de 100 caractères sur les lignes. Le guide WordPress est basé sur le guide jQuery, c'est donc une bonne idée de le lire aussi.

Points-virgules

C'est la règle la plus simple, mais elle est souvent négligée. N'omettez jamais un point-virgule simplement parce que votre code fonctionnera sans lui. C'est juste bâclé.

Indentation

Les tabulations doivent toujours être utilisées pour l'indentation. Vous devez également indenter le contenu d'une fermeture même si le contenu de tout un fichier est contenu dans un. Je ne suis pas sûr de savoir pourquoi mais la fermeture de haut niveau non repentie m'a perturbé avant même d'avoir lu les normes..

Lignes de rupture

Lors de la rupture de longues chaînes, coupez toujours la ligne après un opérateur, ne laissez pas une variable pendant. Cela rend évident à première vue que la ligne est brisée et que vous n’avez pas oublié un point-virgule.

De même, si une condition est longue, divisez-la en plusieurs lignes et ajoutez-y un onglet supplémentaire. Celui-ci a l'air très bizarre à mes yeux mais la séparation qu'il ajoute entre la condition et le corps est très visible.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Cette ligne est composée de' + n + 'mots, elle doit donc être décomposée après' + 'un opérateur';

Itération jQuery

Selon les standards de l'itération jQuery (jQuery.each ()) ne devrait être utilisé que sur des objets jQuery. Vous devriez utiliser la base pour, pour / dans, tandis que boucles en Javascript pour itérer sur d'autres collections.

Conclusion

Il y a beaucoup de choses à noter et à suivre, et il est impossible que quelqu'un applique tout cela en une fois. Vous devez prendre votre code le plus près possible des normes et travailler à les suivre exactement..

À mon avis la cohérence est la règle la plus importante. Il est préférable de faire systématiquement quelque chose de mal que de passer à mi-chemin. Ceci est particulièrement vrai avec les pratiques de formatage, car elles n’affectent pas la fonctionnalité de votre code et - dans la plupart des cas, - peut être facilement modifié par la suite.

Détestez-vous un élément des normes de codage, pensez-vous que quelque chose devrait être ajouté? Faites le nous savoir dans les commentaires!