web-dev-qa-db-fra.com

Est-ce une mauvaise pratique d'utiliser la balise <? = En PHP?

Je suis tombé sur ce PHP tag <?= ?> récemment et j'hésite à l'utiliser, mais ça me démange tellement que je voulais avoir votre avis. Je sais que c'est une mauvaise pratique d'utiliser des balises courtes <? ?> et que nous devrions utiliser des balises complètes <?php ?> à la place, mais qu'en est-il de celui-ci: <?= ?>?

Cela économiserait de la frappe et ce serait mieux pour la lisibilité du code, OMI. Donc au lieu de ça:

<input name="someVar" value="<?php echo $someVar; ?>">

Je pourrais l'écrire comme ceci, qui est plus propre:

<input name="someVar" value="<?= $someVar ?>">

L'utilisation de cet opérateur est-elle mal vue?

200
marco-fiset

Histoire

Avant que le train de désinformation ne sorte trop loin de la gare, il y a un tas de choses que vous devez comprendre à propos des PHP balises courtes.

Le principal problème avec les balises courtes de PHP est que PHP a réussi à choisir une balise (<?) utilisée par une autre syntaxe, [~ # ~] xml [~ # ~] .

Avec l'option activée, vous ne pouviez pas générer de sortie brute de la déclaration xml sans obtenir d'erreurs de syntaxe:

<?xml version="1.0" encoding="UTF-8" ?>

C'est un gros problème lorsque vous considérez à quel point l'analyse et la gestion XML sont courantes.

Qu'en est-il de <?=?

Bien que <? provoque des conflits avec xml, <?= pas. Malheureusement, les options pour l'activer et le désactiver étaient liées à short_open_tag , ce qui signifie que pour bénéficier de la balise d'écho courte (<?=), vous avez dû faire face aux problèmes de la balise ouverte courte (<?). Les problèmes associés à la balise ouverte courte étaient bien plus importants que les avantages de la balise d'écho courte, vous trouverez donc un million et demi de recommandations pour transformer short_open_tag off, que vous devriez.

Avec PHP 5.4, cependant la balise echo courte a été réactivée séparément du short_open_tag option. Je vois cela comme une approbation directe de la commodité de <?=, car il n'y a rien de fondamentalement mauvais en soi.

Le problème est que vous ne pouvez pas garantir que vous aurez <?= si vous essayez d'écrire du code qui pourrait fonctionner dans une plus large gamme de versions PHP.

ok, maintenant que tout est à l'écart

Si vous utilisez <?=?

flowchart about whether or not to use the short echo tag

220
zzzzBov

Dépoussiérer mon PHP chapeau

Je serais certainement favorable à l'utilisation de <?= $someVar ?> sur le plus verbeux echo (simplement une préférence personnelle). L'inconvénient uniquement AFAIK est destiné aux utilisateurs qui exécutent une version antérieure à la version 5.4.0, auquel cas short_open_tag doit être activé dans php.ini .

Cela dit, si votre projet n'est pas OS, c'est un point discutable. Si c'est le cas, je documenterais le fait que short_open_tags doit être activé ou utiliser la plus portable des deux solutions.

30
Demian Brecht

Vous devez absolument essayer d'éviter les balises de formulaire court, que ce soit <? ou <?=.

La principale raison technique est la portabilité, vous ne pouvez jamais être sûr que les balises de formulaire court fonctionneront pour chaque configuration donnée, car elles peuvent être désactivées, recherchez short_open_tag directive. Mais vous pouvez toujours être absolument certain que la forme longue fonctionnera partout.

Cela économiserait de la frappe et ce serait mieux pour la lisibilité du code, OMI.

C'est aussi une mauvaise habitude. Je ne peux pas vraiment vous dire ce que vous trouvez plus lisible, mais je suis fiévreusement contre l'utilisation de la lisibilité du code comme excuse pour vous éviter quelques frappes. Si vous êtes préoccupé par la lisibilité, vous devriez opter pour un moteur de modèle, ceci:

<input name="someVar" value="{someVar}">

est beaucoup plus lisible à partir de vos deux exemples.

Enfin, il convient de noter que les balises de forme courte sont explicitement découragées par les principaux projets PHP, par exemple POIRE et Framework Zend .

21
yannis

PHP-Documentation indique clairement que vous pouvez utiliser des balises d'écho courtes en toute sécurité:

5.4.0 The tag <?= is always available regardless of the short_open_tag ini setting.

Bien que ce soit pour PHP version 5.4 et supérieure mais tout le monde devrait au moins utiliser celui-ci. Je les préférerais à des fins de modèles uniquement.

15
Hexodus

Raisons d'utiliser des balises courtes:

  • Ils sont plus courts.

Raisons pour pas d'utiliser des balises courtes:

  • Ils introduisent une configuration de plus - bien que vous contrôliez le serveur la plupart du temps dans un contexte professionnel, si vous prévoyez de publier votre code au grand public, les balises courtes peuvent se casser de manière irréparable pour les personnes qui l'utilisent sur, par exemple, l'hébergement partagé .
  • Ils rendent beaucoup trop facile de déposer des chaînes non désinfectées dans votre sortie. C'est effrayant car cela peut introduire des vulnérabilités XSS. Bien que les balises longues ne fassent rien directement pour empêcher cela, elles signalent au programmeur que ce qu'elles font n'est peut-être pas la bonne chose, et elles devraient commencer à utiliser un système de modèles qui gère automatiquement le codage HTML pour elles à droite maintenant. La sortie de chaînes dynamiques avec de longues balises est pénible, ce qui est une bonne chose (éducative).
10
tdammers

Je pense que la version <?= Est une bonne pratique/acceptable, à condition que vous ne l'utilisiez que pour la sortie finale des variables et évitez les appels de fonction ou la logique ternaire qui ne sont pas directement liés à la présentation des données.

C'est certainement beaucoup mieux que <? echo($x); ?> partout.

À long terme, vous voudrez peut-être examiner les moteurs de modèles tels que Smarty .

4
Darien

Depuis PHP 7.4, le terrain de jeu change un peu:

<? ?> est officiellement obsolète et sera supprimé dans PHP 8.0.

PHP RFC: Deprecate PHP Short open tags indique explicitement que <?= ?> n'est pas affecté. Cela indiquerait (selon moi, pas le RFC) que son utilisation n'est pas découragée.

3
Etienne Bruines