¿Cuáles son los argumentos EN FAVOR de las etiquetas de cierre de PHP para los archivos solo de PHP?

Question

El estándar de codificación de Zend Framework menciona lo siguiente:

Para los archivos que solo contienen código PHP, la etiqueta de cierre ("?>") Nunca está permitida. PHP no lo requiere, y omitirlo evita la inyección accidental de espacios en blanco en la respuesta.

• Zend Framework coding standard: file formatting

Sin embargo, yo recuerdo haber oído acerca de un tema (con herramientas o incluyendo tal vez?) Donde los archivos necesarios para tener una etiqueta de cierre.

¿Alguien sabe de algún problema (que no sea el problema del desarrollador de querer simetría) donde tendría que tener etiquetas de cierre o son generalmente una mala idea?

Answer 1

La eliminación de las etiquetas de cierre cuando se puede es realmente una mejor práctica. La razón es porque si tienes un carácter (incluso el espacio en blanco) fuera del?> En un archivo php, puede detener algo como los encabezados para dejar de funcionar si el personaje se envía al navegador antes de que se establezca el encabezado.

Answer 2

Nuestra oficina funciona con aplicaciones de aprendizaje electrónico integradas en Flash y descubrimos desde el principio que si la etiqueta de cierre se omite de los scripts del lado del servidor, entonces rompe nuestro mecanismo de comunicación con las aplicaciones e-learnng.

Una advertencia a esto sería que nuestro proceso de depuración no lo intenté primero en un entorno simplificado para asegurarnos de que no era una combinación de las etiquetas de cierre faltantes y alguna salida errónea proveniente de algún otro script. ..

Answer 3

Utilizamos Drupal, que siempre omite la etiqueta de cierre, y nunca tuvo ningún problema debido a ello.

Como siempre funcionó para Drupal (y sabía por leer el manual que era opcional), una vez creé un archivo de configuración (que solo contenía código PHP) sin la etiqueta de cierre. Por alguna razón, no funcionó hasta que (a instancias de un compañero de trabajo) agregué la etiqueta de cierre. No intentamos descubrir la causa en ese momento.

Siempre he usado la etiqueta de cierre en el código que escribo; se ve más simétrico, conceptualmente "cierra" la etiqueta de apertura, y siempre tengo cuidado de no dejar ningún espacio en blanco adicional después de la etiqueta de cierre.

Answer 4

En respuesta a @ gabriel1836, las etiquetas de cierre en el lado del servidor son irrelevantes cuando se trata de aplicaciones Flash; lo relevante es la carga útil devuelta por el servidor en respuesta a una solicitud remota de la aplicación Flash. Omitir la etiqueta de cierre en archivos de solo PHP afectará esto solo para garantizar que la salida espuria no se devuelva antes de enviar los encabezados a su aplicación Flash.

En respuesta a @CesarB, a menos que pueda dar un ejemplo concreto y reproducible, todo lo que hace es propagar FUD. El manual de PHP es muy claro de que la etiqueta de cierre es opcional.

Answer 5

siempre utilizo las etiquetas de cierre, simplemente no se ve bien sin ellas. Tampoco es una xml válida. Instrucciones de procesamiento sin ellos (no importa si lo único en el archivo es php)

Answer 6

Podría considerar la etiqueta de apertura php para archivos php, como una especie de línea shebang (como #!/bin/bash), de esa manera, no necesita una etiqueta de cierre.

Seguimos el estándar ZF también, sin etiqueta de cierre para archivos php-only. Pero nunca escuché de ninguna herramienta que no pudiera analizar un archivo debido a la falta de una etiqueta de cierre, y hasta ahora no he tenido ningún problema para no usarla.

Answer 7

Si usa las etiquetas de cierre de PHP, entonces puede encontrar fácilmente los archivos que se han truncado accidentalmente (por ejemplo, no se han subido por completo).
Sin embargo, dicho problema debe corregirse haciendo que el sistema de archivos y las transferencias sean confiables en lugar de agregar etiquetas PHP "canarias" :)

Otra posible razón es que los estándares de codificación PEAR lo requieren. Lo requieren, porque lo requieren y no tiene permitido cuestionar los estándares de codificación PEAR.

Answer 8

Siempre escribo la etiqueta de cierre para los archivos php, y deliberadamente no la sigo con espacios o eol.

La norma implica que si se omite la etiqueta de cierre, se proporcionará implícitamente uno. Pero eso no exonera al desarrollador de escribir correctamente html/xml.

Y puede haber casos donde se combinan dos archivos fuera del procesamiento html/php, y una etiqueta faltante causaría una aflicción extrema.

Answer 9

Siempre los pongo porque los veo como una llave de cierre de lujo, como cuando escribo condicionales y bucles pongo el par de llaves abiertas/cerradas antes de escribir código, lo hago con archivos PHP.

Ya sea "correcto" o no, semi-frecuentemente me encuentro convirtiendo archivos PHP "puros" en "no puros", y la etiqueta de cierre es extremadamente útil.

Answer 10

La comprobación de errores de codificación no funciona al concatar múltiples archivos. Uso el siguiente comando de shell para verificar si hay errores.

find . -name '*.php' | xargs cat | php -l 

Por supuesto, el siguiente comando todavía funciona (y muestra el nombre de archivo del archivo dañado)

find . -name '*.php' | while read filename; do php -l $filename | grep -v 'No syntax errors '; done 

Pero éste es mucho más lenta.