Est-ce que PHP short tags est acceptable?

je suis trop fan de <?=$whatever?> pour laisser tomber. Jamais eu de problème avec ça. Je vais attendre jusqu'à ce qu'il me mord dans le cul. Sérieusement, 85% des clients (my) ont accès à php.ini dans le rares occasion ils sont éteints. Les 15% restants utilisent des hébergeurs traditionnels, et pratiquement tous les hébergeurs les ont activés. J'aime em.

à partir de PHP 5.4, le raccourci echo est un problème séparé des tags courts, car le raccourci echo sera toujours activé. C'est un fait maintenant:

• Révision SVN par Rasmus Lerdorf
• liste de Diffusion

ainsi le raccourci echo 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 templating. Personne ne prétend que les tags devraient être utilisés dans les fichiers source des applications.

cependant la syntaxe embeddable de PHP lui permet d'être utilisé comme un langage de modèle puissant, et les modèles doivent être aussi simple et lisible que possible. Beaucoup ont trouvé plus facile d'utiliser un moteur de Templier beaucoup plus lent, comme Smarty, mais pour les puristes parmi nous qui exigent un rendu rapide et un 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 supportées sur tous les serveurs. Les commentaires sur les conflits avec les documents XML sont ridicules, parce que vous ne devriez probablement pas mélanger PHP et XML de toute façon; et si c'est le cas, vous devriez utiliser PHP pour produire des chaînes de texte. La sécurité ne devrait jamais être un problème, parce que si vous mettez des informations sensibles comme les justificatifs d'accès à la base de données à l'intérieur de les fichiers de modèles, Eh bien, vous avez de plus gros problèmes!

maintenant, en ce qui concerne la question du support des serveurs, il est vrai qu'il faut être conscient de 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 (comme moi), le client reconnaît (et dépend en effet du fait) que nous allons dicter les exigences du serveur. Souvent, je suis responsable de configurer le 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 la course à beaucoup plus de problèmes que la simple perte de la prise en charge des balises courtes. Il n'a tout simplement pas se produire.

Donc, oui, je suis d'accord que l'utilisation de balises doivent être soigneusement pesés. Mais je crois fermement qu'il devrait TOUJOURS être une option, et qu'un développeur qui est conscient de son environnement doit se sentir libre de les utiliser.

balises Courtes sont de retour grâce à Zend Framework poussant " PHP comme langage de template " dans leur par défaut MVC configuration . Je ne vois pas de quoi parle le débat, la plupart des logiciels que vous produirez de votre vivant fonctionneront sur un serveur que vous ou votre entreprise contrôlerez. Tant que vous restez cohérent, il ne devrait pas y avoir de problèmes.

UPDATE

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

<?php and <?php echo

de plus de

<? and <?=

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

parce que la confusion qu'il peut générer avec les déclarations XML. Beaucoup de gens d'accord avec vous, cependant.

une préoccupation supplémentaire est la douleur qu'il générerait pour coder tout avec des étiquettes courtes seulement pour découvrir à la fin que le serveur d'hébergement final les a éteint...

ci-dessous se trouve le merveilleux schéma du même:

Source: semblable question sur l'Ingénierie du Logiciel Stack Exchange

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php a beaucoup de conseils, y compris:

tandis que certaines personnes trouvent des étiquettes courtes et Étiquettes de style ASP pratique, ils sont moins portable, et généralement pas recommandé.

et

notez que si vous intégrez PHP dans XML ou XHTML vous aurez besoin de utilisez les étiquettes <?php ?> pour rester conforme aux normes.

et

en utilisant des étiquettes courtes doit être évitée lors du développement d'applications ou de les bibliothèques qui sont destinées à redistribution, ou déploiement sur PHP les serveurs qui ne sont pas sous votre contrôle, parce que les étiquettes courtes peuvent ne pas être pris en charge sur le serveur cible. Pour portable, code redistribuable, assurez-vous de ne pas utiliser les balises courtes.

au cas où quelqu'un ferait encore attention à ça... 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 étiquettes courtes sont (a) acceptables et (b) ici pour rester. Du moins pour le moment...

• les balises courtes ne sont pas activées par défaut dans certains serveurs Web (serveurs partagés, etc.), ainsi code portability devient un problème si vous avez besoin de passer à l'un de ces.

• Lisibilité peut être un problème pour certains. Beaucoup de développeurs peuvent trouver que <?php attire l'oeil comme un marqueur plus évident du début d'un bloc de code que <? quand vous scannez un fichier, en particulier si vous êtes coincé avec une base de code avec HTML et PHP étroitement entrelacés.

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

j'ai lu cette page après avoir cherché de l'information sur le sujet, et j'ai le sentiment qu'une question majeure n'a pas été mentionnée: la paresse contre la cohérence. Les" vraies " balises pour PHP sont . Pourquoi? Je n'ai pas vraiment de soins. Pourquoi voudrais-tu utiliser autre chose alors que C'est clairement pour PHP? <% et %> moyenne ASP pour moi, et