Ne fermez pas vos tags à la fin des fichiers PHP

Pendant que NikO nous présente ses conventions de codage, parlons d’une autre bonne pratique concernant les tags de délimitation de blocs en PHP.

Le langage PHP n’impose pas de fermer un bloc de code avec ?> si se bloc se trouve tout à la fin du fichier, et pour cause, mieux vaut l’omettre dans les fichiers susceptibles d’êtres inclus par d’autres !

Prenons ce bout de code :
date.php

Notez bien la ligne blanche après le tag de fermeture. Et maintenant :

redirige.php

Catastrophe ! C’est la très pénible erreur Warning: Cannot modify header information – headers already sent by… qui s’affiche.

PHP a envoyé la ligne blanche (\n) de notre fichier date.php au navigateur, avec les en-têtes HTTP qui vont bien. Impossible d’ajouter de nouveaux en-têtes ni de rediriger l’utilisateur une fois que le début du corps de la requête a été envoyé.

Il faut savoir que certains éditeurs de texte ajoutent automatiquement un retour charriot à la fin des fichier lors de leur création ou de leur enregistrement.

Otez les ?> à la fin de vos classes, bibiliothèques et tout autres fichiers qui seront inclus par d’autres. Même si votre éditeur n’a pas se malheureux comportement, ce n’est peut-être pas le cas de ceux de vos collègues, des contributeurs du projet sur lequel vous travaillez… ou que vous utilisez.

10 comments

  1. Je suis curieux de connaître les mauvais éditeurs de texte qui rajoutent des \n là où il n’en faut pas. Histoire que je les évites.

    Enfin bref, conseiller une mauvaise pratique est de mauvais goût. Surtout quand c’est pour contourner un bogue plutôt que de le résoudre.

    Au fait, la norme PHP n’existe pas. PHP n’est pas un langage normalisé.

  2. Mea culpa, PHP n'est pas normalisé (au sens Java du terme).

    Disons que l'implémentation du langage de The PHP Group ne l'impose pas 😉

    Omettre ce tag peut causer problème en cas d'utilisation du fichier source PHP par un analyseur XML, ce qui est très rare, beaucoup plus que celui d'envoyer involontairement des caractères invisibles après le ?>.

    Après, suivant les cas, ça peut ne pas être super élégant (j'omets ce tag quasi-exclusivement dans mes classes, jamais dans mes templates).

    Voyons ce que la documentation officielle en dit :

    Note: La balise fermante d'un bloc PHP à la fin d'un fichier est optionnel, et parfois, il est utile de l'omettre lors de l'utilisation de la fonction include() ou de la fonction require(), car les espaces non désirés n'apparaîtront pas à la fin des fichiers, et ainsi, vous pourrez toujours ajouter des en-têtes à la réponse plus tard. C'est utile également si vous voulez utiliser l'affichage du buffer et que vous ne voulez pas voir d'espaces blancs ajoutés à la fin des parties générées par les fichiers inclus.

    http://us2.php.net/basic-syntax.instruction-separ

  3. Je viens de jeter un œil au code source du Zend Framework (qui pourrait faire référence vu ses auteurs :P) et à celui de Symfony, deux projets réputés d’excellente facture : tous les deux ne ferment pas les tags en fin de fichiers.

  4. Ça me conforte dans mon opinion sur PHP :p

    Ceci dit, je préfères m’imposer un peu de rigueur, ça ne fait pas de mal (et terminer est la moindre des choses).

    Ensuite c’est une affaire de goût.

  5. php5 justement et dans le future tend à se normaliser de plus en plus au contraire ! Il y a une grande différence entre php4 et php5.
    PHP4 était bien trop laxiste et PHP5 se professionnalise beaucoup plus et demande de plus en plus de la rigueur dans la manière de coder (qui se rapproche on peut allègrement le remarquer de l'ASP3 en terme de rigueur.

    Donc "la norme php n'existe pas ?" J'en doute fort il suffit de voir l'axe que prend zend.

Leave a Reply