Les balises PHP courtes sont-elles acceptables?
Voici les informations selon la documentation officielle :
Il existe quatre paires de balises d'ouverture et de fermeture utilisables en PHP. Deux de ceux-ci,
<?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. Ainsi, bien que certaines personnes trouvent les balises courtes et les balises de style ASP pratiques, elles sont moins portables et généralement pas recommandées .
D'après mon expérience, la plupart des serveurs ont 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?
Ils ne sont pas recommandés car il s'agit d'un PITA si vous devez déplacer votre code sur un serveur sur lequel il n'est pas pris en charge (et que vous ne pouvez pas l'activer). Comme vous le dites, de nombreux hôtes partagés supportent les balises , mais "lots" n'est pas tout. Si vous souhaitez partager vos scripts, il est préférable d'utiliser la syntaxe complète.
Je conviens que <? et <?= sont plus faciles pour les programmeurs que <?php et <?php echo mais il est possible d'effectuer une recherche et un remplacement en bloc tant que vous utilisez le même former à chaque fois (et ne pas mettre des espaces entre eux (par exemple: <? php ou <? =)
Je n'achète pas la lisibilité comme une raison du tout. La plupart des développeurs sérieux ont l’option de la coloration syntaxique à leur disposition.
Comme ThiefMaster le mentionne dans les commentaires, à partir de PHP 5.4, les balises <?= ... ?> sont prises en charge partout, quels que soient les paramètres de balises de raccourci. Cela devrait signifier qu'ils sont sans danger pour le code portable, mais cela signifie qu'il y a alors une dépendance à PHP 5.4+. Si vous souhaitez prendre en charge les versions antérieures à la version 5.4 et que vous ne pouvez pas garantir les balises, vous devrez toujours utiliser <?php echo ... ?>.
En outre, 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 le code portable à long terme et souhaitez passer aux outils les plus modernes, envisagez de modifier ces parties du code.
J'aime trop <?=$whatever?> pour le laisser tomber. Jamais eu de problème avec ça. J'attendrai que ça me morde dans le cul. Très sérieusement, 85% de (mes) clients ont accès à php.ini à la rare occasion de les désactiver. Les 15% restants utilisent des fournisseurs d’hébergement classiques, et pratiquement tous les ont activés. Je les aime.
À partir de PHP 5.4, le raccourci echo est un problème distinct des balises courtes, car le raccourci echo sera toujours activé. C'est un fait maintenant:
Ainsi, le raccourci d'écho lui-même (<?=) est sûr à utiliser maintenant.
Le problème avec toute cette discussion réside dans l'utilisation de PHP comme langage de template. Personne ne soutient que les balises doivent être utilisées dans les fichiers source de l'application.
Cependant, la syntaxe incorporable de PHP lui permet d'être utilisé 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 templates additif 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 afficher des chaînes de texte. La sécurité ne devrait jamais être un problème, car si vous mettez des informations sensibles telles que les informations d'identification d'accès à la base de données à l'intérieur de fichiers de modèle, vous avez de plus gros problèmes!
Maintenant, s’agissant de la question du support des serveurs, il faut bien connaître leur plate-forme cible. Si l'hébergement partagé est une cible probable, les balises courtes doivent être évitées. Mais pour de nombreux développeurs professionnels (tels que moi), le client reconnaît (et dépend du fait même) 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 fournisseur d’hébergement qui ne nous donne pas le contrôle absolu de la configuration du serveur. Dans un tel cas, nous pourrions compter sur beaucoup plus de difficultés que de simplement perdre le support des balises courtes. Cela n'arrive pas.
Alors oui, je suis d’accord pour dire que l’utilisation d’étiquettes courtes doit être soigneusement pesée. Mais je suis également fermement convaincu que cela devrait TOUJOURS être une option et qu'un développeur conscient de son environnement devrait se sentir libre de l'utiliser.
Les balises courtes reviennent grâce à Zend Framework en poussant le " PHP en tant que langage de template " dans leur configuration MVC par défaut . Je ne vois pas en quoi consiste 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.
UPDATE
Après avoir beaucoup travaillé avec Magento , qui utilise la forme longue. En conséquence, je suis passé à la forme longue de:
<?php and <?php echo
plus de
<? and <?=
Cela semble être une petite somme de travail pour assurer l'interopérabilité.
Voici le diagramme de flux merveilleux de la même chose:
Source: question similaire sur Software Engineering Stack Exchange
http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php a beaucoup de conseils, y compris:
bien que certaines personnes trouvent les balises courtes et les balises de style ASP pratiques, elles sont moins portables et ne sont généralement pas recommandées.
et
notez que si vous intégrez PHP dans XML ou XHTML, vous devez utiliser les balises
<?php ?>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 risquent de ne pas être prises en charge sur le serveur cible. Pour le code portable redistribuable, veillez à ne pas utiliser de balises courtes.
Si vous êtes toujours attentif à cela ... À partir de 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 sont (a) acceptables et (b) ici pour rester. Pour l'instant au moins ...
Les balises courtes ne sont pas activées par défaut sur certains serveurs Web (hôtes partagés, etc.), de sorte que la portabilité du code devient un problème si vous devez passer à l'un d'entre eux. de ceux-ci.
La lisibilité peut poser problème pour certains. Beaucoup de développeurs peuvent trouver que
<?phpattire l'attention comme un marqueur plus évident du début d'un bloc de code que<?lorsque vous numérisez un fichier, en particulier si vous êtes bloqué avec une base de code avec - HTML et PHP étroitement entrelacés.
Remarque: à partir de PHP 5.4, la balise courte, <?=, est désormais toujours disponible.
J'ai lu cette page après avoir cherché des informations sur le sujet, et j’ai le sentiment qu’un problème majeur n’a pas été mentionné: la paresse ou la cohérence. Les "vrais" tags pour PHP sont <? Php et?>. Pourquoi? Je m'en fiche. Pourquoi voudriez-vous utiliser quelque chose d'autre alors que ceux-ci sont clairement pour PHP? <% et%> signifient ASP, et <script ..... signifie Javascript (dans la plupart des cas). Donc, pour des raisons de cohérence, d’apprentissage rapide, de portabilité et de simplicité, pourquoi ne pas s’en tenir à la norme?
D'autre part, 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 serait probablement très long de perdre du temps. que beaucoup de temps en tapant les trois caractères supplémentaires de "php" !!
Bien que Nice offre de nombreuses options, ce n’est pas du tout logique et cela peut poser problème. Imaginez si chaque langage de programmation permettait 4 types de balises ou plus: Javascript pourrait être <JS ou <script .... ou <% ou <? JS .... cela serait-il utile? Dans le cas de PHP l'ordre d'analyse a tendance à être en faveur de permettre ces choses, mais le langage n'est pas flexible à bien d'autres égards: il jette des avis ou des erreurs à la moindre incohérence, mais des balises courtes sont utilisées souvent. Et lorsque des balises courtes sont utilisées sur un serveur qui ne les prend pas en charge, il peut s’avérer très long de déterminer ce qui ne va pas car aucune erreur n’est donnée dans certains cas.
Enfin, je ne pense pas que le problème réside ici dans les balises courtes: il n'y a que deux types logiques de blocs de code PHP - 1) de code PHP normal, 2) d'échos de modèles. Pour les premiers, je crois fermement que seuls <? Php et?> Devraient être autorisés uniquement pour que tout soit cohérent et portable. Pour ce dernier, la méthode <? = $ Var?> Est laide. Pourquoi doit-il en être ainsi? Pourquoi ne pas ajouter quelque chose de beaucoup plus logique? <? php $ var?> Cela ne ferait rien (et seulement dans les possibilités les plus éloignées pourrait-il entrer en conflit avec quelque chose), et cela pourrait facilement remplacer la syntaxe maladroite <? =. Ou si cela pose problème, ils pourraient peut-être utiliser <? Php = $ var?> À la place et ne pas s'inquiéter des incohérences.
Au moment où il y a 4 options pour les balises open et close et l'ajout aléatoire d'une balise "echo" spéciale, PHP peut aussi avoir un drapeau "balises open/close personnalisées" dans php.ini ou .htaccess. Ainsi, les concepteurs peuvent choisir celui qui leur convient le mieux. Mais pour des raisons évidentes, c'est exagéré. Alors, pourquoi autoriser plus de 4 options?
Une situation un peu différente concerne le développement d’une application CodeIgniter . CodeIgniter semble utiliser les étiquettes courtes chaque fois que PHP est utilisé dans un modèle/vue, sinon avec les modèles et les contrôleurs, il utilise toujours les balises longues. Ce n’est pas une règle absolue dans le cadre, mais la plupart du temps, le cadre et une grande partie des sources d’autres utilisations suivent cette convention.
Mes deux centimes? Si vous ne prévoyez jamais d'exécuter le code ailleurs, utilisez-le si vous le souhaitez. Je préférerais ne pas avoir à faire une recherche en masse et à la remplacer quand je réalise que c'était une idée stupide.
<? est désactivé par défaut dans les versions plus récentes. Vous pouvez activer ceci comme décrit Activer les balises courtes en PHP.
Avouons-le. PHP est vraiment moche, sans balises courtes.
Vous pouvez les activer dans un fichier .htaccess si vous ne pouvez pas accéder au fichier php.ini:
php_flag short_open_tag on
Il est bon de les utiliser lorsque vous travaillez avec un framework MVC ou un CMS ayant des fichiers de vue séparés.
C'est rapide, moins de code, pas de confusion pour les concepteurs. Assurez-vous simplement que votre configuration de serveur permet de les utiliser.
Les personnes à mon humble avis qui utilisent des balises courtes oublient souvent d’échapper à tout ce qu’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 hack rapide pour échapper aux balises courtes dans les applications Zend Frameworks. Si vous aimez les balises courtes parce que 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) ?>
Pour éviter les problèmes de portabilité, démarrez les balises PHP avec <?php et si votre fichier PHP est purement PHP, pas de HTML, vous n'avez pas besoin d'utiliser les balises de fermeture.
Il faut se demander quel est l'intérêt d'utiliser des balises courtes.
plus rapide à taper
MDCore a déclaré:
<?=est beaucoup plus pratique que de taper<?php echo
Oui, ça l'est. Vous éviterez de devoir taper 7 caractères * X fois dans vos scripts.
Cependant, lorsqu'un script prend une heure, 10 heures ou plus pour concevoir, développer et écrire, quelle est l'importance des quelques secondes de temps ne pas taper ces 7 caractères ici et là pendant toute la durée du script?
Comparé à la possibilité que certains de vos scripts de base, ou la totalité d'entre eux, ne fonctionnent pas si les balises courtes ne sont pas activées, ou si une mise à jour ou une personne modifiant la configuration du fichier/serveur ini les empêche de fonctionner, ainsi que d'autres potentiels.
Le petit avantage que vous gagnez ne compense guère la gravité des problèmes potentiels, à savoir que votre site ne fonctionne pas ou, pire encore, que certaines parties ne fonctionnent pas et donc un mal de tête à résoudre.
Plus facile à lire
Cela dépend de familiarité .
J'ai toujours vu et utilisé <?php echo. Donc, bien que <?= ne soit pas difficile à lire, cela ne m’est pas familier et donc pas plus facile à lire .
Et avec la division des développeurs front-end/back-end (comme dans la plupart des entreprises), un développeur front-office travaillant sur ces modèles serait-il plus familier connaissant <?= est égal à "PHP open tag et echo"?
Je dirais que la plupart seraient plus à l'aise avec le plus logique. C’est-à-dire une balise ouverte claire PHP et ce qui se passe "echo" - <?php echo.
évaluation des risques
Problème = tout le site ou les scripts principaux ne fonctionnent pas;
Le potentiel d'émission est très faible + la gravité du résultat est très élevée = risque élevé
Conclusion
Vous gagnez quelques secondes ici et là, vous n’avez pas à taper quelques caractères, mais vous risquez beaucoup, et vous risquez de perdre la lisibilité.
Les codeurs avant ou arrière familiers avec <?= sont plus susceptibles de comprendre <?php echo, car ils sont standard PHP choses - standard <?php balise ouverte et très connue "echo".
(Même les codeurs frontaux devraient savoir "écho" ou ils ne travailleront tout simplement pas sur un code fourni par un framework).
Alors que l'inverse est moins probable, il est peu probable que quelqu'un déduise logiquement que le signe d'égalité sur une balise courte PHP est "echo".
- Les balises courtes sont acceptables si vous êtes certain que le serveur le supportera 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 de balises de style asp alternées normalisées , comme <% plutôt que <?, qui est un paramètre du fichier php.ini appelé asp_tags. Voici son raisonnement:
... les conventions arbitraires devraient être normalisées. C'est-à-dire que chaque fois que nous sommes confrontés à un ensemble de possibilités d'égale valeur, telles que les ponctuations étranges que notre langage de programmation doit 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 de tout ce que la convention concerne).
Cela me semble bien, mais je ne pense pas qu'aucun d'entre nous puisse encercler les chariots autour de cette cause. En attendant, je m'en tenais au <?php complet.
Convertissez <? (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 (conserver l’espace de fin):
find . -name "*.php" -print0 | xargs -0 Perl -pi -e 's/<\? /<\?php /g'
Je pensais qu'il valait la peine de mentionner qu'à partir de PHP 7:
- Les ASP PHP balises
<% … %>courtes sont parties - Les raccourcis PHP
<? … ?>sont toujours disponibles sishort_open_tagest défini sur true. C'est la valeur par défaut. - Depuis PHP 5.4, les balises courtes Print
<?=… ?>sont toujours activé, quel que soit le réglageshort_open_tag.
Bon débarras pour le premier, car il interférait avec d'autres langues.
Il n'y a maintenant aucune raison de ne pas utiliser les étiquettes à impression courte, en dehors de vos préférences personnelles.
Bien sûr, si vous écrivez du code pour qu'il soit compatible avec les anciennes versions de PHP 5, vous devrez vous en tenir aux anciennes règles, mais souvenez-vous que tout ce qui précède PHP 5.6 est maintenant non pris en charge.
Voir: https://secure.php.net/manual/en/language.basic-syntax.phptags.php
Si vous vous souciez de XSS alors vous devriez utiliser <?= htmlspecialchars(…) ?> la plupart du temps, ainsi une balise courte ne fera pas une grande différence.
Même si vous raccourcissez echo htmlspecialchars() à h(), vous devez toujours vous rappeler de l’ajouter presque à chaque fois (et d’essayer de garder une trace des données pré-échappées, ce qui n’est pas échappé, mais inoffensif fait seulement des erreurs plus probables).
J'utilise n moteur de modélisation qui est sécurisé par défaut et écrit pour moi les balises <?php.
<?php ?> sont beaucoup mieux à utiliser car les développeurs de ce langage de programmation ont mis à jour massivement leur langage de base. 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 en surbrillance plus foncées!
Cependant, faire écho à quelque chose, par exemple: <?=$variable;?> est correct. Mais préférez les balises plus longues. <?php echo $variable;?>
Les balises courtes sont toujours disponibles en php. Donc, vous n'avez pas besoin de faire écho à la première déclaration de votre script
exemple:
$a =10;
<?= $a;//10
echo "Hellow";//
echo "Hellow";
?>
Du coup, vous devez utiliser pour un seul script php, 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>