Share
À ce stade de la série, nous avons couvert beaucoup de terrain. Jusqu'à présent, nous avons abordé les sujets suivants:
Beaucoup de choses, à droite?
Dans cet article en particulier, je pensais que nous allions un peu plus facilement avant de passer au sujet final. En tant que tel, nous allons couvrir deux sujets très simples (qui sont souvent ignorés ou trop compliqués).
Plus précisément, nous allons parler de l'opérateur ternaire et des conditions de Yoda.
Quand il s’agit d’écrire du code basé sur WordPress, les normes de codage disent strictement que nous devrions viser la lisibilité en premier lieu. Tout droit du Codex:
En général, la lisibilité est plus importante que l'habileté ou la brièveté.
Mais là est un peu de nuance à cela. 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 et si le développeur n'est pas habitué à écrire ou à lire l'opérateur ternaire, il enfreint ce principe.
Nous examinerons cela plus en profondeur dans un instant.
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.
Par exemple, disons que nous avons un conditionnel comme ceci:
Accentsconagua
$ uses_gasoline = null; if ('hybrid' == $ car_type) $ uses_gasoline = false; else $ uses_gasoline = true; echo $ uses_gasoline; Bien sûr, ceci est un exemple un peu artificiel, mais vous comprenez le point. Après tout, j'essaie simplement de montrer comment convertir un conditionnel comme celui-ci en un formulaire utilisé par l'opérateur ternaire.
Conformément à l'exemple ci-dessus, vous pouvez effectuer les opérations suivantes:
$ uses_gasoline = 'hybride' == $ car_type? faux vrai; echo $ uses_gasoline;
Avoir un sens? Une chose importante à noter: l'opérateur ternaire teste vrai (plutôt que faux, évidemment).
Pour ce que ça vaut, je trouve que ça ressemble beaucoup à lire une phrase. La première clause pose une question (évidemment ponctuée d'un point d'interrogation), avec les deux réponses possibles renvoyées sur la base de l'évaluation du conditionnel.
Là est une mise en garde pour la vérification de la véracité qui est documentée dans le Codex:
Une exception utiliserait
! vide(), comme test de faux ici est généralement plus intuitif.
D'après mon expérience, c'est le seul moment pour utiliser une évaluation négative dans le conditionnel. Toutes les fois que j'ai passé à travailler avec l'opérateur ternaire, j'ai constaté que le test de faux rend souvent l'évaluation ternaire plus difficile à déchiffrer..
De plus, j’ai trouvé qu’il était préférable de fournir une évaluation unique et peut être deux évaluations dans des circonstances très simples et claires.
Autre que ça, c'est comment utiliser l'opérateur ternaire dans votre travail WordPress quotidien
Si vous suivez de près, vous remarquerez que j'ai fait quelque chose que la plupart des langages de programmation (ou même des plates-formes basées sur PHP en dehors de WordPress) ne font pas régulièrement:
La comparaison du conditionnel a été effectuée en comparant la valeur à la variable; ne pas l'inverse.
Traditionnellement, nous voyions quelque chose comme ceci:
$ uses_gasoline = null; if ($ car_type == 'hybride') $ uses_gasoline = false; else $ uses_gasoline = true; echo $ uses_gasoline;
Et l'opérateur ternaire correspondant ressemblerait à ceci:
$ uses_gasoline = $ car_type == 'hybride'? faux vrai; echo $ uses_gasoline;
Donc, si la majorité des langages de programmation et des plateformes ne pas utiliser les conditions Yoda, alors pourquoi WordPress?
Selon le Codex:
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.
À mon avis, c’est une très très bonne explication pour effectuer des comparaisons comme celle-ci. notamment au sein de langages dynamiquement typés tels que PHP et JavaScript.
Peu importe si vous êtes d'accord avec cette approche ou non, cela est une partie de la norme et vous sont aller voir cela utilisé par le biais de WordPress, thèmes, plugins, articles, etc..
À cette fin, je recommande fortement de commencer à mettre en œuvre dans votre propre travail.
Comme je l'ai mentionné au début, cet article en particulier serait beaucoup plus simple et direct que certains des autres documents que nous avons abordés dans la série jusqu'à présent..
À ce stade, nous n’avons plus qu’un autre sujet important à traiter: Requêtes de base de données..
Après cela, nous examinerons tous les sujets que nous avons décrits tout au long de cette série afin de résumer les principes que nous avons détaillés dans les Normes de codage..
Mais d'abord, aux requêtes de base de données.
