¿Etiqueta de cierre (?>) En archivos PHP?

17

Algunas personas juran al cerrar sus archivos PHP ?>, algunos dicen que está más optimizado para dejarlo.

Sé que no es esencial tenerlo allí, solo me pregunto cuáles son los pros y los contras de hacer esto, y cuál es la mejor práctica.

php code-formatting Steve Robbins
fuente
2
RelevanteIf a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.
Steve Robbins
Algunas personas suponen que la frase "más optimizado" tenía la intención de significar "correrá más rápido". El hablante (cuyo primer idioma puede no ser el inglés) podría haber pensado algo más como "más óptimo" o "una mejor práctica".
Scott C Wilson

Respuestas:

27

No es tanto una cuestión de rendimiento: analizar el seguimiento ?>es trivial y no hará ninguna diferencia notable, a menos que incluya un millón de archivos por segundo.

IIRC, php.net recomienda NO agregar el ?>, y las razones son más o menos así:

  • es innecesario
  • es fácil agregar accidentalmente un espacio en blanco significativo después del ?>, que se enviará al cliente, lo que a su vez puede generar errores oscuros de 'encabezados ya enviados' (esto sucede cuando un archivo incluido contiene espacios en blanco e intenta establecer un encabezado después incluyendo ese archivo)
tdammers
fuente
Basado en las respuestas aquí (particularmente con respecto al espacio en blanco no deseado vacío que causa errores de "encabezados ya enviados"), he cambiado mi hábito de incluir religiosamente un?> Al final de un archivo PHP. Noté que cuando creé un nuevo archivo con PHPStorm, la plantilla acababa de insertar un <? Php sin la etiqueta de cierre?>, Y pensé que era solo una codificación descuidada. Ahora lo se mejor.
tcrosley
Esta razón precisa - "encabezados ya enviados" - fue la razón por la cual mi empleador me ha prohibido rigurosamente (un gran portal web). Una cosa es cuando lo olvida al final de un archivo que acaba de escribir. Es otra si edita una entrada de biblioteca que es 3 incluye profundidad, su editor de texto inserta el espacio en blanco sin que lo sepa, y de repente un pedazo de portal dirigido por chicos a 2 edificios de distancia deja de funcionar. El árbol de incluye es a menudo más de 100 archivos, encontrar el error se convierte en un ejercicio de paciencia. Espere una visita de "gratitud profunda" semanas más tarde cuando encuentre el error y lo rastree hasta usted.
SF.
1
PHP enviando espacios en blanco después de la etiqueta de cierre es otro ejemplo de malas decisiones de lenguaje.
user949300
12

No, están equivocados.

?>es opcional en PHP al final de un archivo. Y encontrarás una buena razón para esto. La más importante es que un espacio vacío al final de un archivo no le impedirá enviar encabezados. Este es un error difícil de detectar porque puedes encontrarlo en cualquier archivo en cualquier lugar.

La forma habitual de hacerlo es poner una etiqueta de cierre cuando PHP se mezcla con HTML y no ponerlo para archivos PHP puros. Incluso es un estándar de codificación del marco ZEND y muchos otros.

Optimizado significa que el código se ejecuta más rápido. Esto es fácil de demostrar que están equivocados. Perfile el código y descubra que le están diciendo tonterías.

deadalnix
fuente
4

Creo que se recomienda a los novatos que eviten agregarlo para que no causen el envío accidental de caracteres adicionales de nueva línea. Dado que no es esencial tenerlo como usted ha mencionado, creo que el razonamiento general es que es mejor dejarlo para evitar errores.

No creo que haya ninguna "optimización" involucrada.

Le señalaría aquí: /programming/4410704/php-closing-tag y aquí: /programming/3219383/why-do-some-scripts-omit-the -closing-php-tag

manojlds
fuente
1
novatos o no ... simplemente no hay razón (a excepción de los casos de OCD) para tenerlos
MCHL
@Mchl me gustaría señalar que las razones para dejar fuera son bastante trivial y, al final, todo se reduce a la preferencia del programador y no es realmente un problema TOC ...
Kenneth
1
Me estremezco cada vez que veo ?>archivos que contienen PHP puro.
Affetor cafeinado
@Kenneth: Si son triviales, no puedo verlos. La parte del TOC fue una broma.
Mchl