¿Por qué se omite la etiqueta de cierre?

374

Sigo leyendo que es una mala práctica usar la etiqueta de cierre de PHP ?>al final del archivo. El problema del encabezado parece irrelevante en el siguiente contexto (y este es el único buen argumento hasta ahora):

Las versiones modernas de PHP establecen el indicador output_buffering en php.ini. Si el buffer de salida está habilitado, puede configurar encabezados HTTP y cookies después de generar HTML porque el código devuelto no se envía al navegador de inmediato.

Todo libro de buenas prácticas y wiki comienza con esta 'regla', pero nadie ofrece buenas razones. ¿Hay otra buena razón para omitir la etiqueta PHP final?

danidacar
fuente
3
posible duplicado de [¿por qué en algunos scripts omiten la etiqueta de cierre de php?>] ( stackoverflow.com/questions/3219383/… )
Gordon
@Christian: ¿Quieres decir que usar output_buffering es vago o dejarlo ?>es vago?
El Yobo
44
@ Gordon: no creo que sea un dup, el OP conoce las razones aparentes, solo quiere saber si se resuelve por completo con el búfer de salida.
El Yobo
55
Una mejor pregunta sería: ¿Por qué uno incluiría la etiqueta de cierre? El código es malo. El mejor código es ningún código en absoluto. Si un problema puede eliminarse en lugar de resolverse con código, es mejor que tener código. En este caso, no hay problema que deba resolverse. El código funciona bien sin la etiqueta de cierre.
still_dreaming_1
19
Oh dios, este no es el lugar para las pestañas vs espacios guerra santa, jajaja :)
Kevin Wheeler

Respuestas:

322

Enviar encabezados antes del curso normal puede tener consecuencias de largo alcance. A continuación se detallan algunos de los que me vinieron a la mente en este momento:

  1. Si bien las versiones actuales de PHP pueden tener almacenado en el búfer de salida, los servidores de producción reales en los que implementará su código son mucho más importantes que cualquier máquina de desarrollo o prueba. Y no siempre tienden a seguir las últimas tendencias de PHP de inmediato.

  2. Puede tener dolores de cabeza por la inexplicable pérdida de funcionalidad . Supongamos que está implementando algún tipo de pasarela de pago y redirige al usuario a una URL específica después de una confirmación exitosa por parte del procesador de pagos. Si se produce algún tipo de error de PHP, incluso una advertencia o un final de línea en exceso, el pago puede permanecer sin procesar y el usuario aún puede parecer no facturado. Esta es también una de las razones por las cuales la redirección innecesaria es mala y si se va a utilizar la redirección, debe usarse con precaución.

  3. Puede obtener el tipo de error "Carga de página cancelada" en Internet Explorer, incluso en las versiones más recientes. Esto se debe a que una respuesta AJAX / incluir json contiene algo que no debería contener, debido al exceso de terminaciones de línea en algunos archivos PHP, tal como lo encontré hace unos días.

  4. Si tiene algunas descargas de archivos en su aplicación, también pueden romperse debido a esto. Y es posible que no lo note, incluso después de años, ya que el hábito de interrupción específico de una descarga depende del servidor, el navegador, el tipo y el contenido del archivo (y posiblemente algunos otros factores con los que no quiero aburrirlo) .

  5. Finalmente, muchos frameworks PHP, incluidos Symfony , Zend y Laravel (no se menciona esto en las pautas de codificación, pero sigue el ejemplo) y el estándar PSR-2 (elemento 2.2) requieren la omisión de la etiqueta de cierre. Manual PHP en sí ( 1 , 2 ), Wordpress , Drupal y muchos otros programas PHP, supongo, aconsejo hacerlo. Si simplemente tiene la costumbre de seguir el estándar (y configura PHP-CS-Fixer para su código), puede olvidar el problema. De lo contrario, siempre tendrá que tener el problema en mente.

Bonificación: algunas trampas (actualmente una) relacionadas con estos 2 personajes:

  1. Incluso algunas bibliotecas bien conocidas pueden contener terminaciones de línea en exceso después ?>. Un ejemplo es Smarty, incluso las versiones más recientes de la rama 2. * y 3. * tienen esto. Entonces, como siempre, esté atento al código de terceros . Bonificación en bonificación: una expresión regular para eliminar terminaciones PHP innecesarias: reemplace (\s*\?>\s*)$con texto vacío en todos los archivos que contienen código PHP.
Halil Özgür
fuente
Regex ligeramente diferente Solía ​​encontrar las etiquetas con Netbeans IDE, para el cuadro de diálogo Buscar y reemplazar: \?>(?s:.){0,10}\Z Breve explicación: changeset.hr/blog/miscellaneous/catch-near-eof-with-regex
frnhr
@Cek, atrapa cualquier texto -incluyendo código- que es de 10 caracteres o menos después ?>: por ejemplo, que coincide -y sería delete- ?> Helloen <?php echo "test"; ?> Hello. Queremos borrar solo las etiquetas cercanas.
Halil Özgür
66
Peor aún, apache 2.4.6 con PHP 5.4 realmente falla en nuestras máquinas de producción cuando hay un espacio vacío detrás de la etiqueta de cierre. Solo perdí horas hasta que finalmente reduje el error con strace. Aquí está el error que Apache tiros: [core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11).
Artem Russakovskii
3
@INTPnerd Oh, la pregunta y la mayoría de las respuestas se refieren al encabezado, por lo que asumí que cualquiera que lea este hilo tendría una idea al respecto. El problema subyacente y la causa real de los problemas en muchas de las respuestas aquí son espacios en blanco innecesarios después ?>, lo que (al igual que cualquier salida) hace que los encabezados se envíen tan pronto como salga. No hay "encabezados HTML" (aparte de la <header>etiqueta HTML5 no relacionada ).
Halil Özgür
2
Esto debería funcionar, independientemente del modificador global: \ s * \?> \ S * \ Z Observe la '\ Z' al final. Asegura que estás capturando una etiqueta de cierre de php si y solo si es el último espacio en blanco al final del archivo.
Erutan409
122

La razón por la que debe dejar la etiqueta de cierre php ( ?>) es para que el programador no envíe accidentalmente caracteres adicionales de nueva línea.

La razón por la que no debe omitir la etiqueta de cierre de php es porque causa un desequilibrio en las etiquetas de php y cualquier programador con media mente puede recordar no agregar espacios en blanco adicionales.

Entonces para su pregunta:

¿Hay otra buena razón para omitir la etiqueta php final?

No, no hay otra buena razón para omitir las etiquetas php finales.

Terminaré con algunos argumentos para no molestarme con la etiqueta de cierre:

  1. Las personas siempre pueden cometer errores, no importa cuán inteligentes sean. Adherirse a una práctica que reduce el número de posibles errores es (en mi humilde opinión) una buena idea.

  2. PHP no es XML. PHP no necesita adherirse a los estándares estrictos de XML para estar bien escrito y ser funcional. Si una etiqueta de cierre faltante te molesta, puedes usar una etiqueta de cierre, no es una regla establecida de una manera u otra.

zzzzBov
fuente
2
> cualquier programador con media mente puede recordar no agregar espacios en blanco adicionales. Aún mejor, cualquier desarrollador con 1/2 mente puede agregar un gancho de precompromiso a SVC para que los espacios finales se eliminen automáticamente: sin complicaciones, sin complicaciones.
BryanH
66
@BryanH, hasta que tenga un archivo donde se requiera espacio en blanco final, pero eso es muy raro.
zzzzBov
1
Tienes razón, por supuesto. Mira la respuesta de Mario para conocer algunas alternativas geniales.
BryanH
> "La razón por la que no debe omitir la etiqueta de cierre de php es porque causa un desequilibrio en las etiquetas de php y cualquier programador con la mente puesta puede recordar no agregar espacios en blanco adicionales". En Windows, tal vez. En sistemas similares a UNIX, todos los archivos terminan con \ ny los programas lo agregan por usted. EDITAR: ¡Ajá! Como se señala a continuación por @mario, PHP come eso, en realidad.
Andrea
2
Aún más significativo es que incluso los programadores con el doble de triple de mente son humanos y olvidan cosas.
Sebastian Mach
57

Es una recomendación de estilo de codificación para novatos , bien intencionada y recomendada por el manual .

  • Evitando ?>sin embargo resuelve simplemente un chorrito de los comunes cabeceras ya enviado causas (salida cruda, BOM , avisos, etc.) y sus problemas de seguimiento.

  • PHP en realidad contiene algo de magia para comer saltos de línea individuales después del ?>token de cierre. Aunque eso tiene problemas históricos , y deja a los recién llegados aún susceptibles a los editores escamosos y luego a barajar inconscientemente en otros espacios en blanco ?>.

  • Estilísticamente, algunos desarrolladores prefieren ver <?phpy ?>como etiquetas SGML / instrucciones de procesamiento XML, lo que implica la coherencia del equilibrio de un token cercano al final. (Que por cierto, es útil para la clase de unión de dependencias que incluye suplantar la carga automática ineficiente de archivo por archivo).

  • De manera poco común, la apertura <?phpse caracteriza como shebang de PHP (y completamente factible por binfmt_misc ), lo que valida la redundancia de una etiqueta de cierre correspondiente.

  • Hay una discrepancia obvia entre las guías clásicas de sintaxis de PHP obligatorias ?>\ny las más recientes (PSR-2) que acuerdan la omisión.
    (Para el registro: Zend Framework postulando uno sobre el otro no implica su superioridad inherente. Es un error pensar que los expertos se sintieron atraídos por el público objetivo de las API difíciles de manejar).

  • Los SCM y los IDE modernos proporcionan soluciones integradas que alivian principalmente el cuidado de etiquetas cercanas.

Desalentar cualquier uso de la ?>etiqueta de cierre simplemente retrasa la explicación del comportamiento de procesamiento básico de PHP y la semántica del lenguaje para evitar problemas poco frecuentes. Todavía es práctico para el desarrollo de software colaborativo debido a las variaciones de competencia en los participantes.

Cerrar variaciones de etiqueta

  • La etiqueta de cierre regular ?> también se conoce como T_CLOSE_TAG"token de cierre".

  • Comprende algunas encarnaciones más, debido a la alimentación mágica de la nueva línea de PHP :

    ?>\n (Salto de línea Unix)

    ?>\r (Retorno de carro, MACs clásicos)

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

    Sin embargo, PHP no admite el salto de línea combinado Unicode NEL(U + 0085).

    Las primeras versiones de PHP tenían compilaciones IIRC que limitaban un poco el agnosticismo de la plataforma (FI incluso solo se usaba >como marcador cercano), que es el origen histórico probable de la evitación de etiqueta cerrada.

  • A menudo se pasa por alto, pero hasta PHP7 los elimina , la regularidad <?phpelemento de obertura puede ser válidamente emparejado con el rara vez se utiliza </script>como símbolo de cierre extraña .

  • La " etiqueta de cierre duro " ni siquiera es una, simplemente creó ese término para analogía. __halt_compilerSin embargo, desde el punto de vista conceptual y de uso se debe reconocer como un token cercano.

    __HALT_COMPILER();
    ?>

    Básicamente, el tokenizador descarta cualquier código o secciones HTML simples a partir de entonces. En particular, los talones de PHAR hacen uso de eso, o su combinación redundante con la ?>que se muestra.

  • Del mismo modo, un vacíoreturn; sustituye infrecuentemente los guiones de inclusión, lo que hace que ninguno ?>con espacios en blanco finales no sea efectivo.

  • Luego hay todo tipo de variaciones de etiqueta de cierre suave / falsa ; menos conocido y raramente utilizado, pero generalmente por tokens comentados :

    • Espaciado simple // ? >para evadir la detección por el tokenizador de PHP.

    • O sustitutos elegantes de Unicode // ﹖﹥(U + FE56 SMALL QUESTION MARK, U + FE65 SMALL ANGLE BRACKET) que una expresión regular puede captar.

    Ambos no significan nada para PHP , pero pueden tener usos prácticos para kits de herramientas externas que no son conscientes de PHP o semi-conscientes. Nuevamente, catme vienen a la mente scripts unidos, con // ? > <?phpconcatenaciones resultantes que retienen en línea la sección anterior del archivo.

Por lo tanto, existen alternativas prácticas pero dependientes del contexto para una omisión de etiqueta cerrada imperativa.

Niñera manual de ?>etiquetas cercanas no es muy contemporánea de ninguna manera. Siempre ha habido herramientas de automatización para eso (incluso si solo sed / awk o regex-oneliners). En particular:

phptags tag tidier

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

Que generalmente se puede usar para --uncloseetiquetas php para código de terceros, o más bien simplemente para solucionar cualquier (y todos) problemas de espacios en blanco / BOM reales:

  • phptags --warn --whitespace *.php

También maneja la --longconversión de etiquetas, etc. para compatibilidad / configuración de tiempo de ejecución.

mario
fuente
77
Sí, las frases contundentes y provocativas atraen votos negativos. Por lo que he leído con el tiempo, dejar de lado el token de cierre no tiene absolutamente ningún inconveniente, siempre y cuando no trabajes con un software que no puede manejar eso. A menos que pueda probar que omitir el cierre de tokens es malo y algo muy novato, mi
voto negativo se
2
@ Pichan: lo permitiré. Pero supongo que no has entendido lo que se dice aquí. Evitar y evitar son dos cosas diferentes. Y los problemas a medio resolver son el resultado del asesoramiento sobre el aceite de serpiente.
mario
66
@mario: Es una recomendación de estilo de codificación para novatos . Estoy en desacuerdo. Todo el Marco Zend omite etiquetas cercanas. Creo que es una elección muy personal, realmente prefiero dejar mi <? Php abierto y no me siento un novato :)
Daniele Vrut
1
¿Qué hay de HTML? ¿Se necesita entonces? Por ejemplo <?php if($var): ?>Hello World<?php endif; ?>??? Soy realmente curioso ya que no se menciona específicamente.
WASasquatch
1
@WASasquatch Sí. Si está cambiando entre el modo HTML y PHP, necesitará tokens cercanos en cualquier caso. (No es realmente relevante para la pregunta original aquí.)
Mario
22

No es una etiqueta ...

Pero si lo tiene, corre el riesgo de tener espacios en blanco después.

Si lo usa como una inclusión en la parte superior de un documento, podría terminar insertando espacios en blanco (es decir, contenido) antes de intentar enviar encabezados HTTP ... lo cual no está permitido.

Quentin
fuente
10
Si no es una etiqueta, ¿qué es?
danidacar
¿Puedes por favor dar un ejemplo? Tal vez mi configuración de php es mala, pero no puedo reproducir el problema.
danidacar
2
file1.php: <?php $i = 1; ?> luego file2.php:<?php include 'file1.php'; header('Location: http://www.google.com');?>
Quentin
1
También hay inconvenientes en el búfer de salida; utiliza más memoria en el servidor (ya que toda la salida debe almacenarse en la RAM hasta que salga; sin almacenarla en el búfer, se va de inmediato). También es un poco más lento. Ninguno de estos será un problema en la mayoría de los casos, pero de todos modos soy flojo, así que ¿por qué no dejar la etiqueta de cierre? Lo uso phpcspara asegurarme de que quede la etiqueta de cierre de cada uno de mis archivos y luego no me preocupo por el búfer de salida :)
El Yobo
1
@danip: si ha establecido el indicador output_buffer en el archivo de configuración de php, no podría reproducir este problema.
Jichao
16

Es bastante útil no dejar entrar el cierre ?>.

El archivo sigue siendo válido para PHP (no es un error de sintaxis) y, como dijo @David Dorward, permite evitar espacios en blanco / líneas de corte (cualquier cosa que pueda enviar un encabezado al navegador) después de ?>.

Por ejemplo,

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

No será válido.

Pero

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

será.

Por una vez, debes ser flojo para estar seguro .

Shikiryu
fuente
3
Es por eso que pongo seguro en cursiva. Evita errores que pueden costarle mucho tiempo por un espacio no deseado después del ?>. seguro puede no ser la buena palabra aquí. De todos modos, no soluciona nada (no es un código malo para evitar cosas, echoaquí habría sido un código incorrecto) pero / y todavía es válido. Demuestra que estoy equivocado en esto.
Shikiryu
No te rechacé, por cierto. Pero mi punto es compatible con el tuyo. No arregla nada. Nunca dije que no era válido, así que no necesito probar nada.
Christian
1
Chouchenos, apuesto a que querías decir seguro, en lugar de seguro. En mi humilde opinión, eso fue demasiado. Te traje de vuelta al punto de partida. ;-) No estabas diciendo lo incorrecto después de todo. Incluso las pautas de desarrollo de PHP lo alientan a hacerlo. De hecho, es mucho mejor confiar en la omisión de etiquetas de cierre, en lugar de en el búfer de salida, por ejemplo. Esto último sería como configurar display_errors en off. Puro engaño. Y una buena posibilidad de que su aplicación no sea portátil. Realmente creo que, por regla general, es mejor no confiar en el búfer de salida en absoluto.
maraspin
1
No quiero cuestionar a las personas que les gusta poner ?>al final de un archivo solo php. pero ¿alguna vez tuvo la necesidad de depurar algún error causado por espacios finales? Además, no todos los servidores están configurados de la misma manera, especialmente cuando se muda a otro host, ya que detectar esos errores lleva mucho tiempo. Si quieres ponerlo, ?>hazlo, si también agregas un poco de espacio final y tu equipo necesita depurarlo, listo para
culpar a
16

Según los documentos , es preferible omitir la etiqueta de cierre si está al final del archivo por la siguiente razón:

Si un archivo es código PHP puro, es preferible omitir la etiqueta de cierre de PHP al final del archivo. Esto evita que se agreguen espacios en blanco accidentales o que se agreguen nuevas líneas después de la etiqueta de cierre de PHP, lo que puede causar efectos no deseados porque PHP comenzará el almacenamiento en búfer de salida cuando el programador no tenga la intención de enviar ningún resultado en ese punto del script.

Manual PHP> Referencia del lenguaje> Sintaxis básica> Etiquetas PHP

Asaph
fuente
10

Bueno, sé el motivo, pero no puedo mostrarlo:

Para los archivos que contienen solo 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 finales en la respuesta.

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

tawfekov
fuente
23
Esa etiqueta "nunca permitida" es probablemente un estándar de codificación de Zend, pero no es una regla de sintaxis para el formato de archivos PHP.
Matt Huggins
9

Bueno, hay dos formas de verlo.

  1. El código PHP no es más que un conjunto de instrucciones de procesamiento XML y, por lo tanto, cualquier archivo con una .phpextensión no es más que un archivo XML que se analiza para el código PHP.
  2. PHP simplemente comparte el formato de instrucción de procesamiento XML para sus etiquetas de apertura y cierre. En base a eso, los archivos con .phpextensiones PUEDEN ser archivos XML válidos, pero no es necesario que lo sean.

Si cree en la primera ruta, entonces todos los archivos PHP requieren el cierre de etiquetas finales. Omitirlos creará un archivo XML no válido. Por otra parte, sin tener una <?xml version="1.0" charset="latin-1" ?>declaración de apertura , no tendrá un archivo XML válido de todos modos ... Por lo tanto, no es un problema importante ...

Si cree en la segunda ruta, eso abre la puerta a dos tipos de .phparchivos:

  • Archivos que contienen solo código (archivos de biblioteca por ejemplo)
  • Archivos que contienen XML nativo y también código (archivos de plantilla, por ejemplo)

En base a eso, los archivos de solo código pueden finalizar sin una ?>etiqueta de cierre . Pero los archivos de código XML no están bien para finalizar sin un cierre ?>ya que invalidaría el XML.

Pero sé lo que estás pensando. Estás pensando qué importa, nunca vas a renderizar un archivo PHP directamente, así que a quién le importa si es XML válido. Bueno, importa si estás diseñando una plantilla. Si es XML / HTML válido, un navegador normal simplemente no mostrará el código PHP (se trata como un comentario). Para que pueda simular la plantilla sin necesidad de ejecutar el código PHP dentro de ...

No digo que esto sea importante. Es solo una vista que no veo expresada con demasiada frecuencia, entonces, ¿qué mejor lugar para compartirla?

Personalmente, no cierro etiquetas en archivos de biblioteca, pero sí en archivos de plantilla ... Creo que es una preferencia personal (y una guía de codificación) basada más que nada difícil ...

ircmaxell
fuente
1
Esto es completamente falso. PHP NO traduce esas etiquetas a XML y, por lo tanto, no se genera desequilibrio.
Drachenkatze
77
@Felicitus: Supongo que te perdiste la parte que dice "No digo que esto sea importante. Es solo una vista que no veo expresada con demasiada frecuencia, así que qué mejor lugar para compartirla ..." No se trata de PHP traducción de etiquetas a XML. Se trata de lo que sucede cuando un archivo se interpreta en un contexto XML (como HTML, o editores, etc.) ... Pero punto perdido ...
ircmaxell
7

Además de todo lo que ya se ha dicho, voy a agregar otra razón que fue un gran dolor para nosotros para depurar.

Apache 2.4.6 con PHP 5.4 en realidad falla en la segmentación en nuestras máquinas de producción cuando hay un espacio vacío detrás de la phpetiqueta de cierre . Solo perdí horas hasta que finalmente reduje el error con strace .

Aquí está el error que arroja Apache:

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

"¿Hay otra buena razón (además del problema del encabezado) para omitir la etiqueta php final?"

No desea generar caracteres de espacio en blanco extraños sin darse cuenta al generar resultados binarios, datos CSV u otros resultados que no sean HTML.

usuario1238364
fuente
1
Un cliente se quejó porque su analizador XML estaba rechazando nuestra salida cuando tenía una línea en blanco adicional al principio. Peor aún, solo estaba sucediendo en un servidor de siete con una línea adicional después de la etiqueta de cierre en un archivo de configuración no revisado.
eswald
5

Pros

Contras

Conclusión

Diría que los argumentos a favor de omitir la etiqueta parecen más fuertes (ayuda a evitar un gran dolor de cabeza con el encabezado () + es "recomendación" PHP / Zend). Admito que esta no es la solución más "hermosa" que he visto en términos de coherencia de sintaxis, pero ¿qué podría ser mejor?

Z escarchado
fuente
2

Como mi pregunta se marcó como un duplicado de esta, creo que está bien publicar por qué NO se puede omitir la etiqueta de cierre ?>por algunas razones deseadas.

  • Con las instrucciones de procesamiento completas, la sintaxis ( <?php ... ?>) de la fuente PHP es un documento SGML válido, que se puede analizar y procesar sin problemas con el analizador SGML. Con restricciones adicionales, también puede ser válido XML / XHTML.

Nada le impide escribir un código XML / HTML / SGML válido. La documentación de PHP es consciente de esto. Extracto:

Nota: Tenga en cuenta también que si está incorporando PHP en XML o XHTML, deberá usar las etiquetas <? Php?> Para seguir cumpliendo con los estándares.

Por supuesto, la sintaxis PHP no es estricta SGML / XML / HTML y usted crea un documento, que no es SGML / XML / HTML, al igual que puede convertir HTML en XHTML para que sea compatible con XML o no.

  • En algún momento es posible que desee concatenar las fuentes. Esto no será tan fácil como simplemente hacerlo cat source1.php source2.phpsi tiene una inconsistencia introducida al omitir las ?>etiquetas de cierre .

  • Sin ?>esto, es más difícil saber si el documento se dejó en modo de escape PHP o en modo de ignorar PHP (la etiqueta PI <?phppuede haberse abierto o no). La vida es más fácil si constantemente deja sus documentos en modo de ignorar PHP. Es como trabajar con documentos HTML bien formateados en comparación con documentos con etiquetas mal cerradas, mal anidadas, etc.

  • Parece que algunos editores como Dreamweaver pueden tener problemas con PI dejado abierto [1] .

Doc
fuente
0

Si entiendo la pregunta correctamente, tiene que ver con el búfer de salida y el efecto que esto podría tener en el cierre / finalización de las etiquetas. No estoy seguro de que sea una pregunta completamente válida. El problema es que el búfer de salida no significa que todo el contenido se almacena en la memoria antes de enviarlo al cliente. Significa que parte del contenido es.

El programador puede vaciar el búfer a propósito, o el búfer de salida, ¿la opción del búfer de salida en PHP realmente cambia la forma en que la etiqueta de cierre afecta la codificación? Yo diría que no es así.

Y tal vez es por eso que la mayoría de las respuestas volvieron al estilo personal y la sintaxis.

Ruz
fuente
0

Hay 2 posibles usos del código php:

  1. Código PHP como definición de clase o definición de función
  2. Utilice PHP como lenguaje de plantilla (es decir, en vistas)

en el caso 1. la etiqueta de cierre es totalmente inútil, también me gustaría ver solo 1 (una) etiqueta abierta de php y NO (cero) etiqueta de cierre en tal caso. Esta es una buena práctica ya que hace que el código sea limpio y separe la lógica de la presentación. Para el caso de presentación (2.), algunos encontraron que es natural cerrar todas las etiquetas (incluso las procesadas por PHP), lo que lleva a la confusión, ya que PHP tiene de hecho 2 casos de uso separados, que no deben mezclarse: lógica / cálculo y presentación

Daniele Cruciani
fuente