Pourquoi omettrait-on la balise close?


374

Je continue de lire que c'est une mauvaise pratique d'utiliser la balise de fermeture PHP ?>à la fin du fichier. Le problème d'en-tête ne semble pas pertinent dans le contexte suivant (et c'est le seul bon argument jusqu'à présent):

Les versions modernes de PHP définissent l'indicateur output_buffering dans php.ini Si la mise en mémoire tampon de sortie est activée, vous pouvez définir des en-têtes HTTP et des cookies après la sortie de HTML car le code renvoyé n'est pas envoyé immédiatement au navigateur.

Chaque livre de bonnes pratiques et wiki commence par cette «règle» mais personne n'offre de bonnes raisons. Y a-t-il une autre bonne raison de sauter la balise PHP de fin?


3
doublon possible de [pourquoi dans certains scripts, ils omettent la balise php de fermeture?>] ( stackoverflow.com/questions/3219383/… )
Gordon

@Christian - Vous voulez dire que l'utilisation de la sortie_buffering est paresseuse, ou laisser de côté ?>est paresseux?
El Yobo

4
@Gordon - Je ne pense pas que ce soit un dup, l'OP connaît les raisons ostensibles, veut juste savoir s'il est complètement résolu avec la mise en mémoire tampon de sortie.
El Yobo

5
Une meilleure question serait: pourquoi inclure la balise de fermeture? Le code est mauvais. Le meilleur code n'est pas du tout un code. Si un problème peut être éliminé au lieu d'être résolu avec du code, c'est mieux que d'avoir du code. Dans ce cas, il n'y a aucun problème à résoudre. Le code fonctionne bien sans la balise close.
still_dreaming_1

19
Oh mon dieu, ce n'est pas l'endroit pour les onglets vs les espaces de la guerre sainte, lol :)
Kevin Wheeler

Réponses:


322

L'envoi d'en-têtes plus tôt que le cours normal peut avoir des conséquences d'une portée considérable. En voici quelques-unes qui me sont venues à l'esprit en ce moment:

  1. Alors que les versions PHP actuelles peuvent avoir une mise en mémoire tampon de sortie, les serveurs de production réels sur lesquels vous déploierez votre code sont beaucoup plus importants que toutes les machines de développement ou de test. Et ils n'ont pas toujours tendance à suivre immédiatement les dernières tendances PHP.

  2. Vous pouvez avoir des maux de tête à cause d'une perte de fonctionnalité inexplicable . Dites, vous implémentez une sorte de passerelle de paiement et redirigez l'utilisateur vers une URL spécifique après confirmation réussie par le processeur de paiement. Si une sorte d'erreur PHP, même un avertissement, ou une fin de ligne excessive se produit, le paiement peut rester non traité et l'utilisateur peut toujours sembler non facturé. C'est également l'une des raisons pour lesquelles la redirection inutile est mauvaise et si la redirection doit être utilisée, elle doit être utilisée avec prudence.

  3. Vous pouvez obtenir des erreurs de type «Chargement de page annulé» dans Internet Explorer, même dans les versions les plus récentes. En effet, une réponse AJAX / json include contient quelque chose qu'elle ne devrait pas contenir, en raison des terminaisons de ligne excessives dans certains fichiers PHP, comme je l'ai rencontré il y a quelques jours.

  4. Si vous avez des téléchargements de fichiers dans votre application, ils peuvent également se casser. Et vous ne le remarquerez peut-être pas, même après des années, car l'habitude de rupture spécifique d'un téléchargement dépend du serveur, du navigateur, du type et du contenu du fichier (et peut-être d'autres facteurs avec lesquels je ne veux pas vous ennuyer) .

  5. Enfin, de nombreux frameworks PHP, y compris Symfony , Zend et Laravel (il n'y a aucune mention de cela dans les directives de codage mais il suit le mouvement) et la norme PSR-2 (point 2.2) nécessitent l'omission de la balise de fermeture. Le manuel PHP lui-même ( 1 , 2 ), Wordpress , Drupal et de nombreux autres logiciels PHP, je suppose, conseille de le faire. Si vous prenez simplement l'habitude de suivre la norme (et de configurer PHP-CS-Fixer pour votre code), vous pouvez oublier le problème. Sinon, vous devrez toujours garder le problème à l'esprit.

Bonus: quelques accrochages (en fait actuellement un) liés à ces 2 personnages:

  1. Même certaines bibliothèques bien connues peuvent contenir des terminaisons de ligne en excès après ?>. Un exemple est Smarty, même les versions les plus récentes des branches 2. * et 3. * l'ont. Donc, comme toujours, surveillez le code tiers . Bonus en bonus: Une expression régulière pour supprimer les terminaisons PHP inutiles: remplacez (\s*\?>\s*)$par du texte vide dans tous les fichiers contenant du code PHP.

Regex un peu différent , je l' habitude de trouver les balises avec Netbeans IDE, pour Rechercher et remplacer boîte de dialogue: \?>(?s:.){0,10}\Z Explication succincte: changeset.hr/blog/miscellaneous/catch-near-eof-with-regex
frnhr

@Cek, il attrape tout texte (y compris le code) de 10 caractères ou moins après ?>: par exemple, il correspond à -et serait supprimé- ?> Hellodans <?php echo "test"; ?> Hello. Nous souhaitons effacer uniquement les balises de fermeture.
Halil Özgür

6
Pire, apache 2.4.6 avec PHP 5.4 détecte en fait des défauts sur nos machines de production quand il y a de l'espace vide derrière la balise de fermeture. J'ai juste perdu des heures jusqu'à ce que je réduise enfin le bug avec strace. Voici l'erreur que apache lancers francs: [core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11).
Artem Russakovskii

3
@INTPnerd Oh, la question et la plupart des réponses se réfèrent à la chose d'en-tête, donc j'ai supposé que toute personne lisant ce fil aurait une idée à ce sujet. Le problème sous-jacent et la cause réelle des problèmes dans de nombreuses réponses ici sont des espaces inutiles après ?>, qui (comme toute sortie) entraînent l'envoi des en-têtes dès leur sortie. Il n'y a pas d '"en-têtes HTML" (autres que la <header>balise HTML5 indépendante ).
Halil Özgür

2
Cela devrait fonctionner, quel que soit le modificateur global: \ s * \?> \ S * \ Z Remarquez le '\ Z' à la fin. Il garantit que vous capturez une balise de fermeture php si et seulement si c'est le dernier espace non blanc à la fin du fichier.
Erutan409

122

La raison pour laquelle vous devez laisser la balise de fermeture php ( ?>) est pour que le programmeur n'envoie pas accidentellement des caractères de nouvelle ligne supplémentaires.

La raison pour laquelle vous ne devriez pas laisser de côté la balise de fermeture php est parce qu'elle provoque un déséquilibre dans les balises php et que tout programmeur ayant la moitié de l'esprit peut se rappeler de ne pas ajouter d'espace blanc supplémentaire.

Donc pour votre question:

Y a-t-il une autre bonne raison de sauter la balise php de fin?

Non, il n'y a pas d' autre bonne raison d'ignorer les balises PHP finales.

Je terminerai avec quelques arguments pour ne pas s'embêter avec la balise de fermeture:

  1. Les gens sont toujours capables de faire des erreurs, peu importe leur intelligence. Adhérer à une pratique qui réduit le nombre d'erreurs possibles est (à mon humble avis) une bonne idée.

  2. PHP n'est pas XML. PHP n'a pas besoin d'adhérer aux normes strictes de XML pour être bien écrit et fonctionnel. Si une balise de fermeture manquante vous ennuie, vous êtes autorisé à utiliser une balise de fermeture, ce n'est pas une règle définie dans un sens ou dans l'autre.


2
> n'importe quel programmeur avec un demi-esprit peut se rappeler de ne pas ajouter d'espace blanc supplémentaire. Encore mieux, tout développeur avec un esprit 1/2 peut ajouter un crochet de pré-validation à SVC afin que tous les espaces de fin soient automatiquement supprimés: pas de chichi, pas de muss.
BryanH

6
@BryanH, jusqu'à ce que vous ayez un fichier où un espace de fin est absolument requis, mais c'est très rare.
zzzzBov

1
Vous avez raison, bien sûr. Découvrez la réponse de mario pour des alternatives très cool.
BryanH

> "La raison pour laquelle vous ne devriez pas laisser de côté la balise de fermeture php est parce qu'elle provoque un déséquilibre dans les balises php et que tout programmeur à demi-esprit peut se rappeler de ne pas ajouter d'espace blanc supplémentaire." Sous Windows, peut-être. Sur les systèmes de type UNIX, tous les fichiers se terminent par \ n et les programmes les ajoutent pour vous. EDIT: Aha! Comme indiqué ci-dessous par @mario, PHP mange cela, en fait.
Andrea

2
Ce qui est encore plus significatif, c'est que même les programmeurs avec le double d'un triple d'esprit sont humains et oublient quelque chose.
Sebastian Mach

57

C'est un recommandation de style de codage pour débutant , bien intentionnée et conseillée par le manuel .

  • L'évitement ?>résout cependant juste un filet des en- têtes communs déjà envoyés (sortie brute, nomenclature , notifications, etc.) et leurs problèmes de suivi.

  • PHP contient en fait de la magie pour manger des sauts de ligne uniques après la ?> jeton de fermeture. Bien que cela ait des problèmes historiques , et laisse les nouveaux arrivants toujours sensibles aux éditeurs floconneux et se déplaçant involontairement dans d'autres espaces blancs après ?>.

  • Sur le plan stylistique, certains développeurs préfèrent afficher <?phpet en ?>tant que balises SGML / instructions de traitement XML, ce qui implique la cohérence de l'équilibre d'un jeton de fermeture. (Ce qui, entre autres, est utile pour la classe de conjonction de dépendances inclut pour supplanter le chargement automatique inefficace fichier par fichier.)

  • Un peu inhabituellement, l'ouverture <?phpest caractérisée comme un shebang PHP (et entièrement réalisable par binfmt_misc ), validant ainsi la redondance d'une balise close correspondante.

  • Il y a une différence évidente entre advise guides de syntaxe PHP classique rendant obligatoire ?>\net plus les récents (PSR-2) s'entendent sur une omission.
    (Pour mémoire: Zend Framework postulant l'un sur l'autre n'implique pas sa supériorité inhérente. C'est une idée fausse que les experts ont été attirés vers / cibler le public des API encombrantes).

  • SCM et IDE modernes fournissent des solutions intégrées qui atténuent principalement le gardiennage d'étiquettes rapprochées.

Décourager toute utilisation du ?> balise close retarde simplement l'explication du comportement de base du traitement PHP et de la sémantique du langage pour éviter les problèmes peu fréquents. Il est toujours pratique pour le développement de logiciels collaboratifs en raison des variations de compétences des participants.

Fermer les variations de balise

  • La balise de fermeture régulière ?> est également appeléeT_CLOSE_TAG "jeton de fermeture".

  • Il comprend quelques incarnations de plus, en raison de la nouvelle ligne magique des PHP :

    ?>\n (Saut de ligne Unix)

    ?>\r (Retour chariot, MAC classiques)

    ?>\r\n (CR / LF, sur DOS / Win)

    NELCependant, PHP ne prend pas en charge le saut de ligne combiné Unicode (U + 0085).

    Les premières versions de PHP avaient des compilations IIRC limitant quelque peu l'agnosticisme de la plate-forme (FI même juste utilisé >comme marqueur de fermeture), qui est l'origine historique probable de l'évitement des balises de fermeture.

  • Souvent négligé, mais jusqu'à ce que PHP7 les supprime , le régulier <?phpjeton d'ouverture peut être valablement jumelé avec le rarement utilisé </script>comme jeton de fermeture impair .

  • Le " hard close tag " n'en est même pas un - vient de faire ce terme pour l'analogie. En termes de conception et d'utilisation, il __halt_compilerconvient toutefois de reconnaître qu'il s'agit d'un signe symbolique proche.

    __HALT_COMPILER();
    ?>

    Ce qui oblige fondamentalement le tokenizer à éliminer tout code ou sections HTML simples par la suite. En particulier, les talons PHAR utilisent cela, ou sa combinaison redondante avec ?>comme illustré.

  • De même, un vide sereturn; substitue rarement aux scripts d'inclusion, ce qui rend tout ?>espace avec des espaces de fin non efficace.

  • Ensuite, il existe toutes sortes de variations de balises de fermeture douce / fausse ; moins connus et rarement utilisés, mais généralement par jetons commentés :

    • // ? >Espacement simple pour échapper à la détection par le tokenizer PHP.

    • Ou des substituts Unicode fantaisistes // ﹖﹥ (U + FE56 PETIT QUESTION MARK, U + FE65 SMALL ANGLE BRACKET) qu'une expression rationnelle peut comprendre.

    Les deux ne signifient rien pour PHP , mais peuvent avoir des utilisations pratiques pour les kits d'outils externes PHP ou semi-conscients. catLes scripts joints à nouveau viennent à l'esprit, avec des // ? > <?phpconcaténations résultantes qui conservent en ligne l'ancien sectionnement de fichiers.

Il existe donc des alternatives contextuelles mais pratiques à une omission impérative de balise de fermeture.

Le babysitting manuel d' ?>étiquettes proches n'est pas très contemporain de toute façon. Il y a toujours eu des outils d'automatisation pour cela (même si ce n'est que sed / awk ou regex-oneliners). En particulier:

phptags tag tidier

https://fossil.include-once.org/phptags/

Ce qui pourrait généralement être utilisé pour --unclosephp des balises pour du code tiers, ou plutôt pour corriger tout (et tous) les problèmes d'espace / de nomenclature réels:

  • phptags --warn --whitespace *.php

Il gère également la --longconversion de balises, etc. pour la compatibilité d'exécution / configuration.


7
Oui, un phrasé brutal et provocateur attire les votes négatifs. D'après ce que j'ai lu au fil du temps, laisser de côté le jeton de fermeture n'a absolument aucun inconvénient tant que vous ne travaillez pas avec un logiciel qui ne peut pas gérer cela. À moins que vous ne puissiez réellement prouver qu'omettre la fermeture des jetons est mauvais et une chose très noob à faire, mon downvote reste;)
jpeltoniemi

2
@Pichan: Je vais le permettre. Mais je suppose que vous n'avez pas bien compris ce qui se dit ici. Éviter et éviter sont deux choses différentes. Et les problèmes à moitié résolus sont le résultat d'un conseil concernant l'huile de serpent.
mario

6
@mario: C'est une recommandation de style de codage pour débutant . Je ne suis pas d'accord. L'ensemble de Zend Framework omet les balises de fermeture. Je pense que c'est un choix très personnel, je préfère vraiment laisser mon <? Php ouvert et je ne me sens pas un novice :)
Daniele Vrut

1
Et le HTML? Est-il alors nécessaire? Par exemple <?php if($var): ?>Hello World<?php endif; ?>??? Je suis vraiment curieux car ce n'est pas spécifiquement mentionné.
WASasquatch

1
@WASasquatch Oui. Si vous passez du mode HTML au mode PHP, vous aurez besoin de près de jetons dans tous les cas. (Pas vraiment pertinent pour la question d'origine ici.)
mario

22

Ce n'est pas un tag…

Mais si vous l'avez, vous risquez d'avoir un espace blanc après.

Si vous l'utilisez ensuite comme inclusion en haut d'un document, vous pourriez finir par insérer un espace blanc (c'est-à-dire du contenu) avant d'essayer d'envoyer des en-têtes HTTP… ce qui n'est pas autorisé.


10
Si ce n'est pas une balise, c'est quoi?
danidacar

Pouvez-vous donner un exemple? Peut-être que ma configuration php est détraquée, mais je ne peux pas reproduire le problème.
danidacar

2
file1.php: <?php $i = 1; ?> puis file2.php:<?php include 'file1.php'; header('Location: http://www.google.com');?>
Quentin

1
La mise en mémoire tampon de sortie présente également des inconvénients; il utilise plus de mémoire sur le serveur (car toutes les sorties doivent être stockées dans la RAM jusqu'à ce qu'elles soient sorties; sans mise en mémoire tampon, elles vont tout de suite). C'est aussi un peu plus lent. Aucun de ces problèmes ne se posera dans la plupart des cas, mais je suis paresseux de toute façon, alors pourquoi ne pas simplement laisser la balise de fermeture? J'utilise phpcspour m'assurer que la balise de fermeture est laissée de chacun de mes fichiers et ensuite je ne m'inquiète pas de la mise en mémoire tampon de sortie :)
El Yobo

1
@danip: Si vous avez défini l'indicateur output_buffer dans le fichier de configuration php, vous ne pouvez pas reproduire ce problème.
Jichao

16

C'est assez utile de ne pas laisser la fermeture ?> .

Le fichier reste valide pour PHP (pas une erreur de syntaxe) et comme @David Dorward l'a dit, il permet d'éviter d'avoir des espaces / lignes de rupture (tout ce qui peut envoyer un en-tête au navigateur) après la ?> .

Par exemple,

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10);
    imagepng ( $img);
?>
[space here]
[break line here]

ne sera pas valide.

Mais

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10 );
    imagepng ( $img );

volonté.

Pour une fois, il faut être paresseux pour être en sécurité .


3
C'est pourquoi j'ai mis sécurisé en italique. Il vous empêche des erreurs qui peuvent vous coûter beaucoup de temps pour un espace indésirable après le ?>. sécurisé n'est peut-être pas le bon mot ici. Quoi qu'il en soit, cela ne règle rien (ce n'est pas un mauvais code pour empêcher les choses, un echoici aurait été un mauvais code) mais / et il est toujours valide. Prouvez-moi mal à ce sujet.
Shikiryu

Je ne t'ai pas déçu, btw. Mais mon point est compatible avec le vôtre. Cela ne règle rien. Je n'ai jamais dit que ce n'était pas valide, je n'ai donc pas besoin de prouver quoi que ce soit.
Christian

1
Chouchenos, je parie que vous vouliez dire sûr, plutôt que sécurisé. À mon humble avis, c'était trop. Vous a ramené à la case départ. ;-) Vous ne disiez pas la mauvaise chose après tout. Même les directives de développement PHP vous encouragent à le faire. Il est en fait beaucoup mieux de s'appuyer sur la fermeture d'une omission de balise plutôt que sur la mise en mémoire tampon de sortie, par exemple. Ce dernier serait comme désactiver les display_errors. Tricherie pure. Et une bonne chance que votre application ne soit pas portable. Je pense vraiment qu'en règle générale, il vaut mieux ne pas se fier du tout à la mise en mémoire tampon de sortie.
maraspin

1
Je ne veux pas questionner les gens qui aiment mettre ?>à la fin d'un fichier php uniquement. mais avez-vous déjà eu besoin de déboguer une erreur causée par des espaces de fin? De plus, tous les serveurs ne sont pas configurés de la même manière, en particulier lorsque vous vous déplacez vers un autre hôte, intercepter les erreurs prend beaucoup de temps. Si vous voulez ?>simplement le faire, si vous ajoutez également un espace de fin et que votre équipe doit déboguer pour être prêt à blâmer sur git ^^
CoffeDeveloper

16

Selon les documents , il est préférable d'omettre la balise de fermeture si elle se trouve à la fin du fichier pour la raison suivante:

Si un fichier est du code PHP pur, il est préférable d'omettre la balise de fermeture PHP à la fin du fichier. Cela empêche l'ajout d'espaces blancs accidentels ou de nouvelles lignes après la balise de fermeture PHP, ce qui peut provoquer des effets indésirables, car PHP commencera la mise en mémoire tampon de la sortie lorsque le programmeur n'a pas l'intention d'envoyer de sortie à ce stade du script.

Manuel PHP> Référence du langage> Syntaxe de base> Balises PHP


10

Eh bien, je connais la raison, mais je ne peux pas la montrer:

Pour les fichiers contenant uniquement du code PHP, la balise de fermeture (?> ) n'est jamais autorisée. Il n'est pas requis par PHP et son omission empêche l'injection accidentelle d'espaces blancs à la fin de la réponse.

Source: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html


23
Cette balise n'étant "jamais autorisée" est probablement une norme de codage Zend, mais ce n'est pas une règle de syntaxe pour le formatage des fichiers PHP.
Matt Huggins

9

Eh bien, il y a deux façons de voir les choses.

  1. Le code PHP n'est rien de plus qu'un ensemble d' instructions de traitement XML , et donc tout fichier avec une .phpextension n'est rien de plus qu'un fichier XML qui se trouve être analysé pour le code PHP.
  2. Il se trouve que PHP partage le format d'instructions de traitement XML pour ses balises d'ouverture et de fermeture. Sur cette base, les fichiers avec des .phpextensions PEUVENT être des fichiers XML valides, mais ils n'ont pas besoin de l'être.

Si vous croyez à la première route, tous les fichiers PHP nécessitent la fermeture des balises de fin. Les omettre créera un fichier XML non valide. Là encore, sans avoir une <?xml version="1.0" charset="latin-1" ?>déclaration d' ouverture , vous n'aurez pas un fichier XML valide de toute façon ... Ce n'est donc pas un problème majeur ...

Si vous croyez au deuxième itinéraire, cela ouvre la porte à deux types de .phpfichiers:

  • Fichiers contenant uniquement du code (fichiers de bibliothèque par exemple)
  • Fichiers contenant du XML natif et également du code (fichiers modèles par exemple)

Sur cette base, les fichiers de code uniquement peuvent se terminer sans ?>balise de fermeture . Mais les fichiers de code XML ne sont pas autorisés à se terminer sans fermeture ?>car cela invaliderait le XML.

Mais je sais à quoi tu penses. Vous pensez à ce qui importe, vous n'allez jamais rendre un fichier PHP directement, alors peu importe si c'est du XML valide. Eh bien, cela importe si vous concevez un modèle. S'il s'agit d'un XML / HTML valide, un navigateur normal n'affichera tout simplement pas le code PHP (il est traité comme un commentaire). Vous pouvez donc simuler le modèle sans avoir à exécuter le code PHP dans ...

Je ne dis pas que c'est important. C'est juste un point de vue que je ne vois pas exprimé trop souvent, alors quel meilleur endroit pour le partager ...

Personnellement, je ne ferme pas les balises dans les fichiers de bibliothèque, mais dans les fichiers de modèle ... Je pense que c'est une préférence personnelle (et une directive de codage) basée plus que tout sur le dur ...


1
C'est complètement faux. PHP ne traduit PAS ces balises en XML, et donc aucun déséquilibre n'est généré.
Drachenkatze du

7
@Felicitus: Je suppose que vous avez raté la partie qui dit "Je ne dis pas que c'est important. C'est juste une vue que je ne vois pas exprimée trop souvent, alors quel meilleur endroit pour la partager ..." Il ne s'agit pas de PHP traduire les balises en XML. Il s'agit de ce qui se passe lorsqu'un fichier est interprété dans un contexte XML (comme HTML, ou des éditeurs, etc.) ... Mais un point manqué ...
ircmaxell

7

En plus de tout ce qui a déjà été dit, je vais ajouter une autre raison qui a été très difficile à déboguer.

Apache 2.4.6 avec PHP 5.4 fait en fait des erreurs de segmentation sur nos machines de production quand il y a de l'espace vide derrière la phpbalise de fermeture . J'ai juste perdu des heures jusqu'à ce que je réduise enfin le bug avec strace .

Voici l'erreur que Apache lance:

[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)

6

"Y a-t-il une autre bonne raison (autre que le problème d'en-tête) pour ignorer la balise php de fin?"

Vous ne voulez pas sortir par inadvertance des caractères d'espaces blancs superflus lors de la génération d'une sortie binaire, de données CSV ou d'une autre sortie non HTML.


1
J'ai eu un client qui se plaignait parce que son analyseur XML refusait notre sortie alors qu'il avait une ligne vierge supplémentaire au début. Pire encore, cela ne se produisait que sur un serveur sur sept avec une ligne supplémentaire après la balise de fermeture dans un fichier de configuration non révisé.
eswald

5

Avantages

Les inconvénients

Conclusion

Je dirais que les arguments en faveur de l'omission de la balise semblent plus forts (aide à éviter les gros maux de tête avec header () + c'est la "recommandation" PHP / Zend). J'avoue que ce n'est pas la plus "belle" solution que j'ai jamais vue en termes de cohérence syntaxique, mais quoi de mieux?


2

Comme ma question a été marquée comme doublon de celle-ci, je pense que c'est OK de poster pourquoi NE PAS omettre la balise de fermeture ?>peut être souhaité pour certaines raisons.

  • Avec la syntaxe complète des instructions de traitement ( <?php ... ?>), la source PHP est un document SGML valide, qui peut être analysé et traité sans problème avec l'analyseur SGML. Avec des restrictions supplémentaires, il peut également s'agir de XML / XHTML valide.

Rien ne vous empêche d'écrire du code XML / HTML / SGML valide. La documentation PHP en est consciente. Extrait:

Remarque: Notez également que si vous intégrez PHP dans XML ou XHTML, vous devrez utiliser les balises <? Php?> Pour rester conforme aux normes.

Bien sûr, la syntaxe PHP n'est pas stricte SGML / XML / HTML et vous créez un document, qui n'est pas SGML / XML / HTML, tout comme vous pouvez transformer HTML en XHTML pour être compatible XML ou non.

  • À un moment donné, vous souhaiterez peut-être concaténer des sources. Ce ne sera pas aussi simple que de le faire simplement cat source1.php source2.phpsi vous avez introduit une incohérence en omettant les ?>balises de fermeture .

  • Sans ?>cela, il est plus difficile de dire si le document a été laissé en mode d'échappement PHP ou PHP ignore (la balise PI <?phppeut avoir été ouverte ou non). La vie est plus facile si vous laissez systématiquement vos documents en mode ignorer PHP. C'est comme travailler avec des documents HTML bien formatés par rapport aux documents avec des balises non fermées, mal imbriquées, etc.

  • Il semble que certains éditeurs comme Dreamweaver peuvent avoir des problèmes avec PI laissé ouvert [1] .


0

Si je comprends bien la question, cela a à voir avec la mise en mémoire tampon de sortie et l'effet que cela pourrait avoir sur les balises de fermeture / fin. Je ne suis pas sûr que ce soit une question tout à fait valable. Le problème est que le tampon de sortie ne signifie pas que tout le contenu est conservé en mémoire avant de l'envoyer au client. Cela signifie qu'une partie du contenu l'est.

Le programmeur peut vider délibérément le tampon ou le tampon de sortie. L'option de tampon de sortie en PHP change-t-elle vraiment la façon dont la balise de fermeture affecte le codage? Je dirais que non.

Et c'est peut-être pour cela que la plupart des réponses sont revenues à un style et à une syntaxe personnels.


0

Il y a 2 utilisations possibles du code php:

  1. Code PHP tel que la définition de classe ou la définition de fonction
  2. Utiliser PHP comme langage de modèle (c'est-à-dire dans les vues)

dans le cas 1. la balise de fermeture est totalement inutile, aussi je voudrais voir juste 1 (une) balise ouverte php et NO (zéro) balise de fermeture dans un tel cas. C'est une bonne pratique car elle rend le code propre et sépare la logique de la présentation. Pour le cas de présentation (2.), certains ont trouvé qu'il était naturel de fermer toutes les balises (même celles traitées par PHP), ce qui conduit à une confusion, car le PHP a en fait 2 cas d'utilisation distincts, qui ne devraient pas être mélangés: logique / calcul et présentation

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.