Les balises PHP courtes sont-elles acceptables?

522

Voici les informations selon la documentation officielle :

Il existe quatre paires différentes de balises d'ouverture et de fermeture qui peuvent être utilisées en PHP. Deux d'entre eux, <?php ?> et <script language="php"> </script>, sont toujours disponibles. Les deux autres sont des balises courtes et des balises de style ASP, et peuvent être activées et désactivées à partir du fichier de configuration php.ini. En tant que tel, bien que certaines personnes trouvent les balises courtes et les balises de style ASP pratiques, elles sont moins portables et généralement déconseillées .

Dans mon expérience , la plupart des serveurs ne sont des balises courtes activées. Dactylographie

<?=

est beaucoup plus pratique que de taper

<?php echo 

La commodité des programmeurs est un facteur important, alors pourquoi ne sont-ils pas recommandés?

MDCore
la source
61
Pour répondre à la question why, je citerais le guide de certification Zend PHP 5: "Les balises courtes étaient, pendant un certain temps, la norme dans le monde PHP; cependant, elles ont l'inconvénient majeur d'être en conflit avec les en-têtes XML et, par conséquent, ont quelque peu tombé au bord du chemin. "
Fluffy
7
Quel est le cas d'utilisation où ce problème survient, cela signifie-t-il que les développeurs ont du mal à générer du XML à l'aide de PHP?
Jon z
9
Supposons que vous ayez des documents XML que vous souhaitez rendre publics, mais que vous souhaitiez que les documents soient analysables en php pour une raison quelconque, vous devez donc rendre .xml analysable par votre navigateur. Vous utilisez des balises courtes pour qu'elles soient activées, et soudainement, le document XML est analysé via les en-têtes XML, cassant les choses. Cela m'a rendu fou en essayant de comprendre cela il y a longtemps. Depuis que les codes courts ont été désactivés sur tous les serveurs que je dirige et que toute équipe avec laquelle j'ai travaillé a dû recourir à du code non court
thenetimp
43
Depuis PHP 5.4.0, la directive short_open_tag n'inclut pas la balise echo courte <?= $example;?> ! Ceci est très important car l'utilisation de toutes les autres balises courtes est considérée comme futile. Quoi qu'il en soit, l'utilisation de la balise d'écho courte est désormais encouragée. Il fournit une base de code plus fluide et plus ordonnée - esp. dans les fichiers de vue. Donc pour PHP> = 5.4.0 <?= ?> peut être utilisé sans réglage short_open_tag . Veuillez ne pas utiliser les autres balises courtes dans votre code. Les codes-dieux deviennent très en colère quand vous le faites ...
Borislav Sabev
6
Je vais ajouter ceci comme un commentaire rapide, car il y a déjà beaucoup trop de réponses longues: <?n'est pas seulement utilisé en XML pour la <?xml version="1.0" ?>déclaration d' ouverture ; c'est la syntaxe générale des "instructions de traitement", le 2ème exemple le plus courant étant <?xml-stylesheet ... ?>. <?phppeut en fait être considéré comme une instruction de traitement valide, comme c'est le cas <?=(comme autorisé dans 5.4+), mais revendiquer l'ensemble <?crée également un conflit inutile entre les syntaxes.
IMSoP

Réponses:

374

Ils ne sont pas recommandés car il s'agit d'un PITA si vous devez déplacer votre code vers un serveur où il n'est pas pris en charge (et vous ne pouvez pas l'activer). Comme vous le dites, de nombreux hôtes partagés prennent en charge les raccourcis, mais «lots» ne sont pas tous. Si vous souhaitez partager vos scripts, il est préférable d'utiliser la syntaxe complète.

Je suis d'accord avec cela <?et <?=sont plus faciles pour les programmeurs que <?phpet <?php echomais il est possible de faire une recherche et un remplacement en bloc tant que vous utilisez le même formulaire à chaque fois (et ne jetez pas dans les espaces (par exemple: <? phpou <? =)

Je n'achète pas du tout la lisibilité comme raison. La plupart des développeurs sérieux ont la possibilité de mettre en évidence la syntaxe.

Comme ThiefMaster le mentionne dans les commentaires, depuis PHP 5.4, les <?= ... ?>balises sont prises en charge partout, quels que soient les paramètres des raccourcis . Cela devrait signifier qu'ils sont sûrs à utiliser dans du code portable, mais cela signifie qu'il y a alors une dépendance à PHP 5.4+. Si vous souhaitez prendre en charge la version antérieure à 5.4 et ne pouvez pas garantir les raccourcis, vous devrez toujours utiliser <?php echo ... ?>.

De plus, vous devez savoir que les balises ASP <%,%>, <% = et la balise de script sont supprimées de PHP 7 . Donc, si vous souhaitez prendre en charge du code portable à long terme et que vous souhaitez passer aux outils les plus modernes, envisagez de modifier ces parties de code.

Oli
la source
91
Donc, l'explication est: ils sont mauvais parce qu'ils ne sont pas pris en charge? Mais pourquoi ne sont-ils pas pris en charge? Parce qu'ils ne font pas partie des spécifications? D'accord, mais pourquoi ne font-ils pas partie des spécifications? Je suis un peu déçu de cette réponse.
Josef Sábl
61
Je ne suis pas ici pour discuter des "grandes questions" comme pourquoi nous sommes ici, comment tout a commencé, etc. C'est tout ce que vous devez savoir.
Oli
39
PHP obligatoire est un moteur de template. : P
Erreur de syntaxe le
49
Les étiquettes courtes ne sont pas supprimées. Uniquement les balises courtes de style ASP.
Brian Lacy
46
Dans le futur (très proche) de PHP 5.4, l'utilisation de <? = Sera séparée de l'activation ou de la désactivation de short_open_tags. <? = n'est pas éliminé, bien au contraire, il est maintenant considéré comme un élément fondamental du langage.
M. Griever
176

J'aime trop le <?=$whatever?>laisser partir. Je n'ai jamais eu de problème avec ça. J'attendrai que ça me mord dans le cul. Sérieusement, 85% de (mes) clients ont accès à php.ini dans les rares cas où ils sont désactivés. Les 15% restants utilisent des hébergeurs traditionnels, et pratiquement tous les ont activés. Je les aime.

Paolo Bergantino
la source
41
@B Seven Si vous essayez d'éviter tous les problèmes théoriques qui pourraient survenir, votre code sera presque certainement inefficace et bogué. Jusqu'à ce que le groupe PHP accepte de supprimer progressivement les balises courtes [et non les balises ASP], le souci d'être mordu est bien moindre, et la solution potentielle bien plus simple, que d'autres choses que vous pouvez passer votre temps à «réparer».
SamGoody
18
si cela vous mord, passez à un meilleur hébergement
Lie Ryan
4
Je ne suis pas vraiment d'accord pour ne pas utiliser quelque chose car il pourrait ne pas être pris en charge. Ne devrions-nous pas utiliser les autres fonctionnalités qui pourraient ne pas être prises en charge sur un serveur? MYSQL vs MYSQLI? Vous perdrez votre temps petit à petit, écrivant encore et encore de longues balises juste pour éviter une toute petite chance de passer un peu de temps pour passer à un meilleur hôte.
Dean Or
2
@BSeven, voulez-vous dire que vous n'utilisez aucune extension PHP, à l'exception de celles fournies par défaut?
Pacerier
143

À partir de PHP 5.4, le raccourci d'écho est un problème distinct des balises courtes, car le raccourci d'écho sera toujours activé. C'est un fait maintenant:

Ainsi, le raccourci d'écho lui-même ( <?=) est sûr à utiliser maintenant.

dukeofgaming
la source
19
Je dirais que c'est le seul "raccourci" nécessaire. <?phppeut être utilisé au début de tous les fichiers de classe, puis vous avez <?=pour vos vues. gagnant-gagnant.
Xeoncross
6
So the echo shortcut itself (<?=) is safe to use... tant que vous êtes à l'aise avec PHP 5.4. Les applications PHP largement distribuées (comme wordpress) n'ont pas le luxe d'exiger la version 5.4, et ont même continué à offrir une prise en charge de PHP 4 jusqu'en 2011, soit 7 ans après la sortie de PHP 5. Si vous êtes dans un endroit comme Facebook, où toutes les installations de votre logiciel sont directement exploitées par l'entreprise elle-même, alors nécessiter une assistance 5.4 est beaucoup plus facile que si vous travaillez sur un projet comme WordPress.
Frank Farmer
@dukeofgaming, Wow good catch, ne savait pas que leurs révisions SVN sont accessibles sur le web.
Pacerier
82

Le problème avec toute cette discussion réside dans l'utilisation de PHP comme langage de template. Personne ne fait valoir que les balises devraient être utilisées dans les fichiers source de l'application.

Cependant, la syntaxe intégrable de PHP permet de l'utiliser comme un langage de modèle puissant, et les modèles doivent être aussi simples et lisibles que possible. Beaucoup ont trouvé plus facile d'utiliser un moteur de création de modèles beaucoup plus lent, comme Smarty, mais pour les puristes parmi nous qui exigent un rendu rapide et une base de code pure, PHP est le seul moyen d'écrire des modèles.

Le SEUL argument valable CONTRE l'utilisation de balises courtes est qu'elles ne sont pas prises en charge sur tous les serveurs. Les commentaires sur les conflits avec les documents XML sont ridicules, car vous ne devriez probablement pas mélanger PHP et XML de toute façon; et si vous l'êtes, vous devriez utiliser PHP pour sortir des chaînes de texte. La sécurité ne devrait jamais être un problème, car si vous placez des informations sensibles comme les informations d'identification d'accès à la base de données dans des fichiers de modèle, eh bien, vous avez de plus gros problèmes!

Maintenant, en ce qui concerne la question de la prise en charge des serveurs, il faut certes être conscient de leur plateforme cible. Si l'hébergement partagé est une cible probable, les balises courtes doivent être évitées. Mais pour de nombreux développeurs professionnels (comme moi), le client reconnaît (et en effet, cela dépend du fait) que nous dicterons les exigences du serveur. Souvent, je suis responsable de la configuration du serveur moi-même.

Et nous ne travaillons JAMAIS avec un hébergeur qui ne nous donne pas le contrôle absolu de la configuration du serveur - dans un tel cas, nous pourrions compter sur des problèmes bien plus importants que de simplement perdre le support des balises courtes. Cela n'arrive tout simplement pas.

Alors oui - je conviens que l'utilisation de balises courtes doit être soigneusement pesée. Mais je crois aussi fermement que cela devrait TOUJOURS être une option, et qu'un développeur qui connaît son environnement devrait se sentir libre de les utiliser.

Brian Lacy
la source
6
Si, pour une raison quelconque, vous aviez apache configuré pour passer des fichiers .xml à mod_php, la chose <? Xml serait un casse-tête avec des balises courtes. Mais c'est évidemment une configuration bizarre.
Frank Farmer
3
Un langage de modèles qui ne peut pas être incorporé sans solutions de contournement dans certains types de documents de sortie est un gros échec. La seule raison pour laquelle je ne devrais pas avoir de modèle XML avec du code PHP et des balises courtes, c'est parce que cela ne fonctionne pas, pas parce que cela n'a pas de sens.
Vinko Vrsalovic
8
Ce n'est pas un "gros échec" de profiter des avantages de PHP en tant que langage de template rapide et pratique. Comme je l'ai déjà dit, il s'agit de peser les avantages et les inconvénients et d'écrire du code d'une manière qui s'adapte à l'approche choisie. Ne rejetez pas catégoriquement une approche valide simplement parce qu'elle ne fonctionne pas dans un scénario particulier (qui peut facilement être contourné).
Brian Lacy
5
Je ne rejette catégoriquement aucune approche valable (voir ma réponse à la question.) Vous êtes celui qui rejette catégoriquement PHP en XML, je cite: "vous ne devriez pas mélanger PHP et XML de toute façon". De plus, le gros échec auquel je faisais référence était la décision de l'utiliser <?comme balise courte, car cela conduit à des solutions de contournement moches sur XML. Cela dit, je conviens qu'il s'agit de peser les avantages et les inconvénients, et que si vous savez ce que vous faites, vous pouvez certainement le faire. Mais cela ne fait pas <?un bon choix.
Vinko Vrsalovic
3
Je suis un peu en retard à la fête, mais j'aime vraiment cette réponse, et elle reflète mon expérience de la situation. Bien que nous ayons un certain désaccord sur la question dans notre bureau, je peux dire qu'avec un travail quasi quotidien en php pendant de nombreuses années, je n'ai jamais rencontré de problème. Lorsque PHP est utilisé pour générer du XML, d'après mon expérience, il a toujours été dans le contexte d'un contenu hautement dynamique, qui n'a jamais été directement calqué sur PHP, donc le problème ne se pose jamais.
redreinard
33

Les balises courtes reviennent grâce à Zend Framework poussant le " PHP comme langage de modèle " dans leur configuration MVC par défaut . Je ne vois pas de quoi parle le débat, la plupart des logiciels que vous produirez au cours de votre vie fonctionneront sur un serveur que vous ou votre entreprise contrôlerez. Tant que vous restez cohérent, il ne devrait y avoir aucun problème.

MISE À JOUR

Après avoir fait pas mal de travail avec Magento , qui utilise une forme longue. En conséquence, je suis passé à la forme longue de:

<?php and <?php echo

plus de

<? and <?=

On dirait une petite quantité de travail pour assurer l'interopérabilité.

Jake McGraw
la source
8
Je travaille en freelance et tout mon code va sur l'hébergement mutualisé, donc aucun contrôle du tout! :)
MDCore
12
Si vous avez suffisamment de clients qui migrent vers votre propre coloc, l'hébergement partagé est peu sûr et instable.
Jake McGraw
2
Les balises courtes que Zend rapportait n'ont apparemment pas été détectées car Zend utilise la version longue: framework.zend.com/manual/en/zend.view.scripts.html
Gerry
3
@Gerry J'ai également lu ceci récemment, voir le dernier commentaire sur ce sujet: Mettre à jour .htaccess pour activer les balises ouvertes courtes
MrWhite
2
Vous devriez vraiment corriger la grammaire dans la première phrase après UPDATE, ce qui n'a aucun sens dans sa forme actuelle.
redreinard
22

Parce que la confusion qu'il peut générer avec des déclarations XML. Cependant, beaucoup de gens sont d' accord avec vous.

Une préoccupation supplémentaire est la douleur que cela engendrerait pour tout coder avec des balises courtes pour découvrir à la fin que le serveur d'hébergement final les a désactivés ...

Vinko Vrsalovic
la source
La déclaration XML ne causera-t-elle pas une confusion de toute façon si short_tags est activé?
MDCore
Ainsi, au lieu de sortir directement la déclaration XML, vous avez l'écho de PHP. Ce n'est pas vraiment un bon réfut.
moo
Ce n'est pas une réfutation de quoi que ce soit. C'est la seule raison réelle qui est à son tour la cause de l'autre raison "l'hébergeur l'éteint", bien sûr, vous pouvez l'utiliser si vous savez ce que vous faites, comme toujours.
Vinko Vrsalovic
1
@macek: J'en suis conscient. Ce n'était que le premier exemple auquel j'ai pensé. Un autre, et si vous intégrez PHP dans un fichier XML? Vous ne pouvez pas le faire directement. Et ne me dites pas non plus la solution à ce problème, je les connais. Le fait est qu'il existe de nombreuses façons pour PHP d'analyser un fichier XML. Vous pouvez probablement les rejeter tous avec des solutions de contournement ( <?='<?xml') ou en disant «vous ne devriez pas faire ça» mais cela ne fait pas disparaître le fait que cela peut arriver.
Vinko Vrsalovic
1
en quoi les balises courtes sont-elles pénibles si elles ne fonctionnent pas? il est très facile de le faire en vrac et de le remplacer <?=par <? echo . de nombreux éditeurs de texte peuvent facilement gérer cela sur des milliers de fichiers à la fois.
Yamiko
20

Voici le magnifique organigramme du même:

arbre de prise de décision de l'utilisation de <? =

Source: question similaire sur Software Engineering Stack Exchange

Sumoanand
la source
2
Ceci décrit s'il faut utiliser la balise d'écho courte, pas la même chose que les <?balises courtes mentionnées dans la question (bien qu'elle ait utilisé le même paramètre de configuration avant la 5.4)
Alok
En fait, cela devrait être une réponse que tout le monde peut comprendre, bien que les circonstances ne expliquent pas vraiment pourquoi vous ne voulez pas utiliser de balises courtes dans de nombreux cas (par exemple, vous ne pouvez pas modifier le fichier php.ini sur un système d'hébergement partagé)
Björn K
14

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php contient de nombreux conseils, notamment:

Bien que certaines personnes trouvent les balises courtes et les balises de style ASP pratiques, elles sont moins portables et généralement déconseillées.

et

notez que si vous intégrez PHP dans XML ou XHTML, vous devrez utiliser les <?php ?>balises pour rester conforme aux normes.

et

L'utilisation de balises courtes doit être évitée lors du développement d'applications ou de bibliothèques destinées à la redistribution ou au déploiement sur des serveurs PHP qui ne sont pas sous votre contrôle, car les balises courtes peuvent ne pas être prises en charge sur le serveur cible. Pour le code portable et redistribuable, veillez à ne pas utiliser de balises courtes.

Oliver Charlesworth
la source
14

Au cas où quelqu'un y prêterait encore attention ... Depuis PHP 5.4.0, Alpha 1 <?=est toujours disponible:

http://php.net/releases/NEWS_5_4_0_alpha1.txt

Il semble donc que les balises courtes soient (a) acceptables et (b) ici pour rester. Pour l'instant au moins ...

James Alday
la source
5
<?=n'est pas considéré comme une balise courte en date du 5.4
T0xicCode
12
  • Les balises courtes ne sont pas activées par défaut sur certains serveurs Web (hôtes partagés, etc.), donc la portabilité du code devient un problème si vous devez passer à l'un d'entre eux.

  • La lisibilité peut être un problème pour certains. De nombreux développeurs peuvent trouver que cela <?phpattire l'attention comme un marqueur plus évident du début d'un bloc de code que <?lorsque vous analysez un fichier, en particulier si vous êtes coincé avec une base de code avec HTML et PHP étroitement imbriqués.

ConroyP
la source
2
Les balises courtes sont activées dans 95% des serveurs Web.
Paolo Bergantino
19
Je n'achète pas l'argument "lisibilité". Si vous utilisez PHP comme langage de template, <?= $var ?>est beaucoup plus lisible que<?php echo $var ?>
Frank Farmer
2
@Paulo cela a peut-être changé depuis '08 mais les instances EC2 Ubuntu et Fedora avec yum install et les versions apt-get de PHP ont le marquage court désactivé par défaut
Doug Molineux
2
utilisez des balises complètes et vous aurez 100% :)
Elvis Ciotti
1
@FrankFarmer, je pense qu'il compare celui sans écho. <?vs <?php.
Pacerier
11

Remarque: à partir de PHP 5.4, la balise courte,, <?=est désormais toujours disponible.

brunoais
la source
5

J'ai lu cette page après avoir cherché des informations sur le sujet, et je pense qu'un problème majeur n'a pas été mentionné: la paresse vs la cohérence. Les "vraies" balises pour PHP sont <? Php et?>. Pourquoi? Je m'en fiche vraiment. Pourquoi voudriez-vous utiliser autre chose alors que ceux-ci sont clairement pour PHP? <% et%> signifie ASP pour moi, et <script ..... signifie Javascript (dans la plupart des cas). Donc, pour la cohérence, l'apprentissage rapide, la portabilité et la simplicité, pourquoi ne pas vous en tenir à la norme?

D'un autre côté, je conviens que les balises courtes dans les modèles (et UNIQUEMENT dans les modèles) semblent utiles, mais le problème est que nous venons de passer tellement de temps à en discuter ici, qu'il faudrait probablement beaucoup de temps pour avoir réellement gaspillé autant de temps à taper les trois caractères supplémentaires de "php" !!

Bien qu'avoir de nombreuses options soit agréable, ce n'est pas du tout logique et cela peut causer des problèmes. Imaginez si chaque langage de programmation autorisait 4 types de balises ou plus: Javascript pourrait être <JS ou <script .... ou <% ou <? JS .... serait-ce utile? Dans le cas de PHP, l'ordre d'analyse a tendance à être favorable à ces choses, mais le langage n'est pas flexible à bien d'autres égards: il émet des avis ou des erreurs sur la moindre incohérence, mais des balises courtes sont souvent utilisées. Et lorsque des balises courtes sont utilisées sur un serveur qui ne les prend pas en charge, cela peut prendre très longtemps pour comprendre ce qui ne va pas, car aucune erreur n'est donnée dans certains cas.

Enfin, je ne pense pas que les balises courtes soient le problème ici: il n'y a que deux types logiques de blocs de code PHP - 1) du code PHP normal, 2) des échos de modèle. Pour les premiers, je crois fermement que seuls <? Php et?> Devraient être autorisés juste pour garder tout cohérent et portable. Pour ce dernier, la méthode <? = $ Var?> Est moche. Pourquoi doit-il en être ainsi? Pourquoi ne pas ajouter quelque chose de beaucoup plus logique? <? php $ var?> Cela ne ferait rien (et ce n'est que dans les possibilités les plus éloignées que cela pourrait entrer en conflit avec quelque chose), et cela pourrait facilement remplacer la syntaxe maladroite <? =. Ou si c'est un problème, ils pourraient peut-être utiliser <? Php = $ var?> À la place et ne pas se soucier des incohérences.

Au moment où il existe 4 options pour les balises d'ouverture et de fermeture et l'ajout aléatoire d'une balise spéciale "echo", PHP peut également avoir un indicateur "balises d'ouverture / fermeture personnalisées" dans php.ini ou .htaccess. De cette façon, les concepteurs peuvent choisir celui qu'ils préfèrent. Mais pour des raisons évidentes, c'est exagéré. Alors pourquoi autoriser 4+ options?

Daniel Ross
la source
4

Il est bon de les utiliser lorsque vous travaillez avec un framework MVC ou un CMS qui ont des fichiers d'affichage séparés.
C'est rapide, moins de code, pas déroutant pour les concepteurs. Assurez-vous simplement que la configuration de votre serveur permet de les utiliser.

Greg
la source
4

Une situation un peu différente est lors du développement d'une application CodeIgniter . CodeIgniter semble utiliser les raccourcis chaque fois que PHP est utilisé dans un modèle / vue, sinon avec les modèles et les contrôleurs, il utilise toujours les longues balises. Ce n'est pas une règle stricte et rapide dans le cadre, mais pour la plupart, le cadre et une grande partie de la source provenant d'autres utilisations suivent cette convention.

Mes deux centimes? Si vous ne prévoyez jamais d'exécuter le code ailleurs, utilisez-les si vous le souhaitez. Je préfère ne pas avoir à faire une recherche massive et à remplacer quand je me rends compte que c'était une idée stupide.

patricksweeney
la source
4

<?est désactivé par défaut dans les versions plus récentes. Vous pouvez activer ceci comme décrit l' activation des balises courtes en PHP .

AnkTech Devops
la source
Il est désactivé par défaut dans les anciennes versions non plus.
Pacerier
3

Les personnes à mon humble avis qui utilisent des balises courtes oublient souvent d'échapper à tout ce dont elles font écho. Ce serait bien d'avoir un moteur de template qui s'échappe par défaut. Je crois que Rob A a écrit un petit hack pour échapper aux balises courtes dans les applications Zend Frameworks. Si vous aimez les balises courtes car cela rend PHP plus facile à lire. Alors Smarty pourrait-il être une meilleure option?

{$myString|escape}

pour moi ça a l'air mieux que

<?= htmlspecialchars($myString) ?> 
Adrian Judd
la source
10
Pour la plupart des programmeurs PHP, la deuxième option a plus de sens que la première, tout simplement parce que c'est une fonction PHP réelle que nous connaissons, tandis que la première option est un code de pseudo-modèle que nous devons apprendre en plus de PHP. PHP est déjà un langage de template, ajouter un autre langage de template en plus comme Smarty est IMO redondant.
Bug Magnet
3
Twig est un moteur de template avec échappement html activé par défaut twig.sensiolabs.org
mateusza
3

Il faut se demander quel est l'intérêt d'utiliser des balises courtes.

Saisie plus rapide

MDCore a déclaré:

<?= est beaucoup plus pratique que de taper <?php echo

Oui, ça l'est. Vous économisez d'avoir à taper 7 caractères * X fois tout au long de vos scripts.

Cependant, lorsqu'un script prend une heure, ou 10 heures, ou plus, pour concevoir, développer et écrire, quelle est la pertinence des quelques secondes de temps à ne pas taper ces 7 caractères ici et là pendant la durée du script?

Comparé au potentiel de certains ou de tous vos scripts ne fonctionnant pas si les balises courtes ne sont pas activées ou sont activées, mais une mise à jour ou une modification de la configuration du fichier / serveur ini les empêche de fonctionner, d'autres potentiels.

Le petit avantage que vous gagnez ne dépasse pas la gravité des problèmes potentiels, c'est-à-dire que votre site ne fonctionne pas, ou pire, que certaines parties ne fonctionnent pas et donc un mal de tête à résoudre.

Plus facile à lire

Cela dépend de la familiarité .
J'ai toujours vu et utilisé <?php echo. Donc, même si ce <?=n'est pas difficile à lire, ce n'est pas familier pour moi et donc pas plus facile à lire .

Et avec la répartition des développeurs front-end / back-end (comme avec la plupart des entreprises), un développeur front-end travaillant sur ces modèles serait-il plus familier en sachant que <?=c'est égal à "PHP open tag and echo"?
Je dirais que la plupart seraient plus à l'aise avec la plus logique. Autrement dit, une balise ouverte PHP claire et ensuite ce qui se passe "echo" - <?php echo.

Évaluation des risques
Problème = le site entier ou les scripts principaux ne fonctionnent pas;

Le potentiel du problème est très faible + la gravité du résultat est très élevée = risque élevé

Conclusion

Vous économisez quelques secondes ici et là sans avoir à taper quelques caractères, mais vous risquez beaucoup pour cela, et vous perdrez probablement la lisibilité en conséquence.

Avant ou dorsaux codeurs familiers avec <?=sont plus susceptibles de comprendre <?php echo, car ils sont des choses standards PHP - standard <?phpétiquette ouverte et très bien connus « écho ».
(Même les codeurs frontaux devraient connaître "echo" ou ils ne travailleront tout simplement pas sur n'importe quel code servi par un framework).

Alors que l'inverse n'est pas aussi probable, quelqu'un n'est pas susceptible de déduire logiquement que le signe égal sur une balise PHP courte est "echo".

James
la source
Cela n'a rien à voir avec la saisie. Il est plus court et a donc le potentiel d'être plus facile à lire . Une personne habituée à lire <?=lira <?=plus facilement qu'une personne habituée à <?php echolire <?php echo.
Pacerier
@Pacerier Shorter n'est pas simplement = plus facile à lire. Nous sommes tous différents. Vous voulez dire que c'est plus facile à lire pour vous . Comme je l'ai dit dans ma réponse, car j'ai l'habitude de <?phpvoir que le code est souvent plus familier dans le code que <?=- la familiarité facilite les choses - mais pas nécessairement mieux.
James
Non, je ne vous compare pas à moi, je dis qu'une personne habituée à lire <?=lira <?=mieux qu'une personne habituée à <?php echolire <?php echo. Cela signifie que si nous avons deux copies identiques de la personne X, et que nous ne les modifions que dans l'aspect par lequel l'une est habituée à la lecture <?=et l'autre qui est habituée à la lecture <?php echo, la première copie peut atteindre la valeur de lisibilité de la xlecture en utilisant la syntaxe souhaitée, tandis que la deuxième copie peut atteindre la valeur de lisibilité de ylors de la lecture de sa syntaxe souhaitée, où x >= y.
Pacerier
Non, vous manquez le point. Je parle du potentiel du système, qui n'a rien à voir avec une personne en particulier. Vous pouvez dire que les gens habitués à taper avec le clavier qwerty taperont plus rapidement avec qwerty, tandis que les gens habitués à taper avec dvorak taperont plus rapidement avec dvorak, mais le fait ne change pas que les deux systèmes ont un potentiel différent.
Pacerier
3

Avouons-le. PHP est moche comme l'enfer sans balises courtes.

Vous pouvez les activer dans un .htaccessfichier si vous ne pouvez pas accéder à php.ini:

php_flag short_open_tag on
Jimmer
la source
3
Faux. Parfois, le serveur est configuré pour refuser tout type de priorité, monsieur.
Alfabravo
17
Certes, mais si votre hôte ne vous autorise pas à remplacer avec htaccess, vous avez vraiment besoin d'un nouvel hôte! :)
Brian Lacy
1
ne fonctionne pas sur l'interface de ligne de commande et php_flag n'est pas pris en charge tout le temps
Elvis Ciotti
3

Pour éviter les problèmes de portabilité, démarrez les balises PHP avec <?phpet si votre fichier PHP est purement PHP, pas de HTML, vous n'avez pas besoin d'utiliser les balises de fermeture.

Kumar
la source
2
  • Les balises courtes sont acceptables dans les cas où vous êtes certain que le serveur le prendra en charge et que vos développeurs le comprendront.
  • De nombreux serveurs ne le prennent pas en charge et de nombreux développeurs le comprendront après l'avoir vu une fois.
  • J'utilise des balises complètes pour assurer la portabilité, car ce n'est vraiment pas si mal.

Cela dit, un de mes amis a dit cela, à l'appui d'une alternative normalisée balises de style asp , comme <%plutôt que <?, qui est un paramètre dans php.ini appelé asp_tags. Voici son raisonnement:

... les conventions arbitraires devraient être normalisées . Autrement dit, chaque fois que nous sommes confrontés à un ensemble de possibilités qui sont toutes de valeur égale - comme la ponctuation étrange que notre langage de programmation devrait utiliser pour se démarquer - nous devons choisir une méthode standard et nous y tenir. De cette façon, nous réduisons la courbe d'apprentissage de toutes les langues (ou quelles que soient les choses auxquelles la convention se rapporte).

Cela me semble bien, mais je pense qu'aucun d'entre nous ne peut contourner les wagons autour de cette cause. En attendant, je m'en tiendrai au maximum <?php.

stéréoscott
la source
2

J'ai pensé qu'il valait la peine de mentionner qu'à partir de PHP 7:

  • Balises PHP ASP courtes <% … %> ont disparu
  • De courts onglets PHP <? … ?>sont toujours disponibles sishort_open_tag est défini sur true. C'est la valeur par défaut.
  • Depuis PHP 5.4, les balises Short Print<?=… ?> sont toujours activées, quel que soit le short_open_tagparamètre.

Bon débarras du premier, car il interférait avec d'autres langues.

Il n'y a maintenant aucune raison de ne pas utiliser les balises d'impression courtes, en dehors de vos préférences personnelles.

Bien sûr, si vous écrivez du code pour être compatible avec les anciennes versions de PHP 5, vous devrez vous en tenir aux anciennes règles, mais rappelez-vous que tout ce qui précède PHP 5.6 n'est plus pris en charge.

Voir: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Manngo
la source
1
Sauf erreur, votre premier point est incorrect. Le document indique que les balises ASP, et non les balises PHP courtes, ont disparu à partir de PHP 7.0.0.
reformé
@reformed Vous avez absolument raison. Je vais modifier ma réponse. Merci
Manngo
1

Si vous vous souciez de XSS, vous devez utiliser<?= htmlspecialchars(…) ?> plupart du temps, donc une balise courte ne fait pas une grande différence.

Même si vous raccourcissez echo htmlspecialchars()àh() , il est encore un problème que vous devez vous rappeler d'ajouter presque à chaque fois (et en essayant de garder une trace des données qui est pré-échappé, ce qui est, mais non échappés Inoffensif ne fait que des erreurs plus probable).

J'utilise un moteur de modèles sécurisé par défaut et écrit des <?phpbalises pour moi.

Kornel
la source
7
Si vous vous retrouvez à taper "<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 fois par jour, vous pouvez créer une fonction de raccourci nommée" h "comme Rails has .." < ? = h ($ text)?> "est tellement plus lisible lors de la numérisation d'un modèle.
Alexander Malfait
1
C'est mieux en effet, mais avec un moteur de template ça peut être simplement $ {text} ou autre (et vous n'avez pas besoin de vous rappeler d'ajouter h ())
Kornel
7
PHP lui-même est un moteur de template. Lorsque vous arrêtez d'utiliser des balises courtes, cela commence à être un mauvais moteur de modélisation car il devient trop verbeux.
Josef Sábl
1
@Alexander Malfait c'est une bonne astuce. Mais le <? = N'est pas nécessaire. Vous pouvez simplement faire en sorte que la fonction fasse écho à la chaîne au lieu de retourner, alors vous écririez <? Php h ('hello')?> Ne le faisons-nous pas déjà lorsque nous définissons i18n? <? php _e ('')?> n'est pas si mal.
VladFr
1

<?php ?>sont beaucoup mieux à utiliser puisque les développeurs de ce langage de programmation ont massivement mis à jour leur langage principal. Vous pouvez voir la différence entre les balises courtes et les balises longues.

Les étiquettes courtes seront surlignées en rouge clair tandis que les plus longues seront surlignées plus foncées!

Cependant, faire écho à quelque chose, par exemple: <?=$variable;?>c'est bien. Mais préférez les balises plus longues.<?php echo $variable;?>

M50Scripts
la source
1

Convertir <?(sans espace de fin) en <?php(avec un espace de fin):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

Convertir <?(avec un espace de fin) en <?php(en conservant l'espace de fin):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
Fatih Akgun
la source
1

Les balises courtes sont toujours disponibles en php. Vous n'avez donc pas besoin d'écho de la première déclaration de votre script

exemple:

    $a =10;
    <?= $a;//10 
    echo "Hellow";//
    echo "Hellow";

   ?>

Soudain, vous devez utiliser un seul script php, puis vous pouvez l'utiliser. exemple:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>
GaziAnis
la source
1

À partir de 2019, je ne suis pas d'accord avec certaines réponses ici. Je recommande d'utiliser de longues balises

<?php /* code goes here */ ?>

ou balises d'écho courtes

<?= /* code goes here */ ?>

Motif: Ils sont recommandés par la norme de codage de base PSR-1

D'autres balises courtes comme <? /* code goes here */ ?>ne sont pas recommandées.

La spécification dit:

Le code PHP DOIT utiliser les balises longues ou les balises à écho court; il NE DOIT PAS utiliser les autres variantes de balises .

Blackbam
la source
1

3 balises sont disponibles en php:

  1. balise de forme longue qui <?php ?>n'a pas besoin de directive de configuration
  2. short_open_tag qui est <? ?> disponible si l'option short_open_tag dans php.ini est activée
  3. raccourcir la balise <?= depuis php 5.4.0, il est toujours disponible

de php 7.0.0 asp et la balise de script sont supprimés

GaziAnis
la source
Cela ne répond pas à la question.
RalfFriedl
-5

Non, et ils sont progressivement supprimés par PHP 6, donc si vous appréciez la longévité du code, ne les utilisez tout simplement pas ou les <% ... %>balises.

coderGeek
la source
4
J'ai vu d'autres articles de blog qui disent qu'ils ne seront pas dépréciés, juste les balises courtes de style ASP.
MDCore
22
Il semble que cette réponse soit incorrecte, selon ce lien de la réunion des développeurs PHP: php.net/~derick/…
Charles
7
POURQUOI sont-ils si mauvais, pourquoi? Tout le monde est tellement sûr de lui qu'il est baaaaaad mais personne ne dit pourquoi.
Josef Sábl
6
FAUX. Ils suppriment <%%> les balises, comme ils le devraient. Ils ne servent qu'à confondre. Le <? ?> les balises ne seront pas affectées; mais bien sûr, ils sont toujours configurables par serveur, et vous devez toujours être conscient des exigences de votre plate-forme cible.
Brian Lacy
6
Ces informations semblent être incorrectes et trompeuses, et elles devraient être corrigées par l'auteur.
tex