¿Son aceptables las etiquetas cortas de PHP?

Aquí está la información de acuerdo con la documentación oficial :

Hay cuatro pares diferentes de etiquetas de apertura y cierre que se pueden usar en PHP. Dos de ellos <?php ?> y <script language="php"> </script>siempre están disponibles. Las otras dos son etiquetas cortas y etiquetas de estilo ASP, y se pueden activar y desactivar desde el archivo de configuración php.ini. Como tal, aunque algunas personas encuentran convenientes las etiquetas cortas y las etiquetas de estilo ASP, son menos portátiles y generalmente no se recomiendan .

En mi experiencia la mayoría de los servidores no tienen habilitadas las etiquetas cortas. Mecanografía

<?=

es mucho más conveniente que escribir

<?php echo 

La conveniencia de los programadores es un factor importante, entonces, ¿ por qué no se recomiendan?

No se recomiendan porque es un PITA si alguna vez tiene que mover su código a un servidor donde no es compatible (y no puede habilitarlo). Como usted dice, una gran cantidad de servidores compartidos hacen shorttags apoyo, pero "lotes" no es todo de ellos. Si desea compartir sus scripts, es mejor usar la sintaxis completa.

Estoy de acuerdo con eso <?y soy <?=más fácil con los programadores que <?phpy, <?php echopero es posible hacer una búsqueda y reemplazo masivo siempre que use el mismo formulario cada vez (y no tire espacios) (por ejemplo: <? phpo <? =)

No compro la legibilidad como una razón en absoluto. Los desarrolladores más serios tienen la opción de resaltado de sintaxis disponible para ellos.

Como ThiefMaster menciona en los comentarios, a partir de PHP 5.4, las <?= ... ?>etiquetas son compatibles en todas partes, independientemente de la configuración de las etiquetas cortas . Esto debería significar que son seguros de usar en código portátil, pero eso significa que hay una dependencia de PHP 5.4+. Si desea admitir versiones anteriores a la 5.4 y no puede garantizar etiquetas cortas, deberá utilizarlas <?php echo ... ?>.

Además, debe saber que las etiquetas ASP <%,%>, <% = y la etiqueta de script se eliminan de PHP 7 . Entonces, si desea admitir código portátil a largo plazo y desea cambiar a las herramientas más modernas, considere cambiar esas partes del código.

Soy demasiado aficionado <?=$whatever?>para dejarlo ir. Nunca tuve un problema con eso. Esperaré hasta que me muerda el culo. Con toda seriedad, el 85% de (mis) clientes tienen acceso a php.ini en la rara ocasión en que están apagados. El otro 15% usa proveedores de alojamiento convencionales, y prácticamente todos los tienen habilitados. Los amo

Comenzando con PHP 5.4, el atajo de eco es un problema separado de las etiquetas cortas, ya que el atajo de eco siempre estará habilitado. Es un hecho ahora:

• Revisión de SVN por Rasmus Lerdorf
• Discusión de la lista de correo

Entonces el atajo de eco en sí mismo ( <?=) es seguro de usar ahora.

El problema con toda esta discusión radica en el uso de PHP como lenguaje de plantillas. Nadie argumenta que las etiquetas deben usarse en los archivos fuente de la aplicación.

Sin embargo, la sintaxis incorporable de PHP permite que se use como un poderoso lenguaje de plantillas, y las plantillas deben ser lo más simples y legibles posible. A muchos les ha resultado más fácil usar un motor de plantillas adicional mucho más lento como Smarty, pero para aquellos puristas que exigen un procesamiento rápido y una base de código puro, PHP es la única forma de escribir plantillas.

El ÚNICO argumento válido CONTRA el uso de etiquetas cortas es que no son compatibles con todos los servidores. Los comentarios sobre conflictos con documentos XML son ridículos, porque probablemente no deberías mezclar PHP y XML de todos modos; y si es así, debería usar PHP para generar cadenas de texto. La seguridad nunca debería ser un problema, porque si está colocando información confidencial como credenciales de acceso a la base de datos dentro de los archivos de plantilla, ¡entonces tiene problemas más grandes!

Ahora bien, en cuanto a la cuestión del soporte del servidor, hay que tener en cuenta su plataforma de destino. Si el alojamiento compartido es un objetivo probable, entonces se deben evitar las etiquetas cortas. Pero para muchos desarrolladores profesionales (como yo), el cliente reconoce (y de hecho depende del hecho) que dictaremos los requisitos del servidor. A menudo soy responsable de configurar el servidor yo mismo.

Y NUNCA trabajamos con un proveedor de alojamiento que no nos dé un control absoluto de la configuración del servidor; en tal caso, podríamos contar con muchos más problemas que simplemente perder el soporte de etiquetas cortas. Simplemente no sucede.

Entonces sí, estoy de acuerdo en que el uso de etiquetas cortas debe sopesarse cuidadosamente. Pero también creo firmemente que SIEMPRE debería ser una opción, y que un desarrollador que conozca su entorno debería sentirse libre de usarlos.

Las etiquetas cortas están regresando gracias a Zend Framework que empuja el " PHP como lenguaje de plantilla " en su configuración MVC predeterminada . No veo de qué se trata el debate, la mayor parte del software que producirá durante su vida operará en un servidor que usted o su empresa controlarán. Mientras te mantengas constante, no debería haber ningún problema.

ACTUALIZAR

Después de trabajar bastante con Magento , que usa forma larga. Como resultado, he cambiado a la forma larga de:

<?php and <?php echo

terminado

<? and <?=

Parece una pequeña cantidad de trabajo para asegurar la interoperabilidad.

Debido a la confusión que puede generar con declaraciones XML. Muchas personas están de acuerdo con usted, sin embargo.

Una preocupación adicional es el dolor que generaría codificar todo con etiquetas cortas solo para descubrir al final que el servidor de alojamiento final los ha apagado ...

A continuación se muestra el maravilloso diagrama de flujo de la misma:

Fuente: pregunta similar sobre el intercambio de pila de ingeniería de software

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php tiene muchos consejos, que incluyen:

Si bien algunas personas consideran convenientes las etiquetas cortas y las etiquetas de estilo ASP, son menos portátiles y generalmente no se recomiendan.

y

tenga en cuenta que si está incrustando PHP en XML o XHTML, deberá usar las <?php ?>etiquetas para cumplir con los estándares.

y

Se debe evitar el uso de etiquetas cortas al desarrollar aplicaciones o bibliotecas destinadas a la redistribución o la implementación en servidores PHP que no están bajo su control, ya que las etiquetas cortas pueden no ser compatibles con el servidor de destino. Para el código portátil y redistribuible, asegúrese de no usar etiquetas cortas.

En caso de que alguien siga prestando atención a esto ... A partir de PHP 5.4.0 Alpha 1 <?=siempre está disponible:

http://php.net/releases/NEWS_5_4_0_alpha1.txt

Por lo tanto, parece que las etiquetas cortas son (a) aceptables y (b) están aquí para quedarse. Por ahora al menos...

• Las etiquetas cortas no están activadas de forma predeterminada en algunos servidores web (hosts compartidos, etc.), por lo que la portabilidad del código se convierte en un problema si necesita pasar a uno de estos.

• La legibilidad puede ser un problema para algunos. Muchos desarrolladores pueden encontrar que <?phpllama la atención como un marcador más obvio del comienzo de un bloque de código que <?cuando escanea un archivo, particularmente si está atascado con una base de código con HTML y PHP estrechamente entrelazados.

Nota: a partir de PHP 5.4, la etiqueta corta <?=, ahora está siempre disponible.

Leí esta página después de buscar información sobre el tema, y ​​siento que no se ha mencionado un problema importante: la pereza frente a la coherencia. Las etiquetas "reales" para PHP son <? Php y?>. ¿Por qué? Realmente no me importa ¿Por qué querrías usar algo más cuando esos son claramente para PHP? <% y%> significa ASP para mí, y <script ..... significa Javascript (en la mayoría de los casos). Entonces, para lograr consistencia, aprendizaje rápido, portabilidad y simplicidad, ¿por qué no apegarse al estándar?

Por otro lado, estoy de acuerdo en que las etiquetas cortas en las plantillas (y SOLO en las plantillas) parecen útiles, pero el problema es que hemos pasado tanto tiempo discutiéndolo aquí, que probablemente tomaría mucho tiempo desperdiciarlo tanto tiempo escribiendo los tres caracteres adicionales de "php" !!

Si bien tener muchas opciones es bueno, no es lógico y puede causar problemas. Imagínese si cada lenguaje de programación permitiera 4 o más tipos de etiquetas: Javascript podría ser <JS o <script .... o <% o <? JS ... ¿eso sería útil? En el caso de PHP, el orden de análisis tiende a estar a favor de permitir estas cosas, pero el lenguaje en muchas otras formas no es flexible: arroja avisos o errores sobre la más mínima inconsistencia, aunque a menudo se usan etiquetas cortas. Y cuando se usan etiquetas cortas en un servidor que no las admite, puede llevar mucho tiempo descubrir qué está mal, ya que en algunos casos no se produce ningún error.

Finalmente, no creo que las etiquetas cortas sean el problema aquí: solo hay dos tipos lógicos de bloques de código PHP: 1) código PHP normal, 2) ecos de plantilla. Para el primero, creo firmemente que solo se debe permitir que <? Php y?> Se mantenga todo consistente y portátil. Para este último, el método <? = $ Var?> Es feo. ¿Por qué debe ser así? ¿Por qué no agregar algo mucho más lógico? <? php $ var?> Eso no haría nada (y solo en las posibilidades más remotas podría entrar en conflicto con algo), y eso podría reemplazar fácilmente la incómoda sintaxis <? =. O si eso es un problema, tal vez podrían usar <? Php = $ var?> En su lugar y no preocuparse por las inconsistencias.

En el punto donde hay 4 opciones para abrir y cerrar etiquetas y la adición aleatoria de una etiqueta especial "echo", PHP también puede tener una bandera de "etiquetas de apertura / cierre personalizadas" en php.ini o .htaccess. De esa forma, los diseñadores pueden elegir el que más les guste. Pero por razones obvias, eso es exagerado. Entonces, ¿por qué permitir 4+ opciones?

Es bueno usarlos cuando trabaja con un marco MVC o CMS que tienen archivos de vista separados.
Es rápido, menos código, no es confuso para los diseñadores. Solo asegúrese de que la configuración de su servidor permita usarlos.

Una situación que es un poco diferente es cuando se desarrolla una aplicación CodeIgniter . CodeIgniter parece usar las etiquetas cortas cada vez que se usa PHP en una plantilla / vista, de lo contrario con los modelos y controladores siempre usa las etiquetas largas. No es una regla dura y rápida en el marco, pero en su mayor parte, el marco y gran parte de la fuente de otros usos sigue esta convención.

¿Mis dos centavos? Si nunca planea ejecutar el código en otro lugar, utilícelos si lo desea. Prefiero no tener que hacer una búsqueda masiva y reemplazarla cuando me doy cuenta de que fue una idea tonta.

<?está deshabilitado de forma predeterminada en las versiones más recientes. Puede habilitar esto como se describe Habilitando etiquetas cortas en PHP .

En mi humilde opinión, las personas que usan etiquetas cortas a menudo se olvidan de escapar de lo que hacen eco. Sería bueno tener un motor de plantillas que se escape por defecto. Creo que Rob A escribió un truco rápido para escapar de las etiquetas cortas en las aplicaciones de Zend Frameworks. Si te gustan las etiquetas cortas porque hace que PHP sea más fácil de leer. Entonces, ¿podría Smarty ser una mejor opción?

{$myString|escape}

para mí eso se ve mejor que

<?= htmlspecialchars($myString) ?> 

Uno tiene que preguntarse cuál es el punto de usar etiquetas cortas.

Más rápido para escribir

MDCore dijo:

<?= es mucho más conveniente que escribir <?php echo

Sí lo es. Ahorra tener que escribir 7 caracteres * X veces a lo largo de sus scripts.

Sin embargo, cuando un guión demora una hora, o 10 horas, o más, para diseñar, desarrollar y escribir, ¿qué tan relevantes son los pocos segundos de tiempo que no escriben esos 7 caracteres aquí y allá durante la duración del guión?

En comparación con la posibilidad de que algunos de sus núcleos, o todos, no funcionen si las etiquetas cortas no están activadas, o están activadas, pero una actualización o alguien que cambia la configuración del servidor / archivo ini deja de funcionar, otras posibilidades.

El pequeño beneficio que obtiene no se acerca a superar la gravedad de los posibles problemas, es decir, que su sitio no funciona o, lo que es peor, que solo algunas partes no funcionan y, por lo tanto, es un dolor de cabeza para resolver.

Más fácil de leer

Esto depende de la familiaridad .
Siempre he visto y usado <?php echo. Entonces, aunque <?=no es difícil de leer, no me resulta familiar y, por lo tanto, no es más fácil de leer .

Y con la división de desarrolladores front-end / back-end (como con la mayoría de las empresas), ¿sería más familiar para un desarrollador front-end que trabaja en esas plantillas saber que <?=es igual a "PHP open tag and echo"?
Yo diría que la mayoría se sentiría más cómoda con la más lógica. Es decir, una etiqueta abierta PHP clara y luego lo que está sucediendo "echo" -<?php echo .

Evaluación de riesgos
Problema de = todo el sitio o los scripts centrales no funcionan;

El potencial de problema es muy bajo + la gravedad del resultado es muy alta = alto riesgo

Conclusión

Ahorras unos segundos aquí y allá sin tener que escribir algunos caracteres, pero arriesgas mucho por ello y también es probable que pierdas legibilidad como resultado.

Extremo frontal o posterior codificadores familiarizados con <?=son más propensos a entender <?php echo, ya que son cosas normales de PHP - estándar de <?phpetiqueta abierta y muy bien conocidos "eco".
(Incluso los programadores de front end deberían saber "echo" o simplemente no estarán trabajando en ningún código servido por un framework).

Mientras que lo contrario no es tan probable, no es probable que alguien deduzca lógicamente que el signo igual en una etiqueta corta PHP es "echo".

Seamos sinceros. PHP es feo como el infierno sin etiquetas cortas.

Puede habilitarlos en un .htaccessarchivo si no puede acceder a php.ini:

php_flag short_open_tag on

Para evitar problemas de portabilidad, inicie las etiquetas PHP con <?phpy en caso de que su archivo PHP sea puramente PHP, no HTML, no necesita usar las etiquetas de cierre.

• Las etiquetas cortas son aceptables para usar en casos en los que esté seguro de que el servidor lo admitirá y que sus desarrolladores lo entenderán.
• Muchos servidores no lo admiten, y muchos desarrolladores lo entenderán después de verlo una vez.
• Utilizo etiquetas completas para garantizar la portabilidad, ya que realmente no es tan malo.

Dicho esto, un amigo mío dijo esto, en apoyo de etiquetas de estilo asp estandarizadas alternativas , como en <%lugar de <?, que es una configuración en php.ini llamada asp_tags. Aquí está su razonamiento:

... las convenciones arbitrarias deberían estandarizarse . Es decir, cada vez que nos enfrentamos a un conjunto de posibilidades que son todas de igual valor, como la puntuación extraña que nuestro lenguaje de programación debe usar para demarcarse, debemos elegir una forma estándar y seguirla. De esa forma, reducimos la curva de aprendizaje de todos los idiomas (o cualesquiera que sean las cosas a las que pertenece la convención).

A mí me suena bien, pero no creo que ninguno de nosotros pueda rodear los vagones en torno a esta causa. Mientras tanto, me apegaría al máximo <?php.

Pensé que valía la pena mencionar que a partir de PHP 7:

• Las etiquetas cortas de PHP ASP <% … %>se han ido
• Las pestañas cortas de PHP <? … ?>todavía están disponibles si short_open_tagse establece en verdadero. Este es el valor predeterminado.
• Desde PHP 5.4, las etiquetas de impresión corta siempre<?=… ?> están habilitadas, independientemente de la configuración.short_open_tag

Buen viaje al primero, ya que interfiere con otros idiomas.

Ahora no hay ninguna razón para no usar las etiquetas de impresión corta, aparte de las preferencias personales.

Por supuesto, si está escribiendo código para que sea compatible con las versiones heredadas de PHP 5, deberá atenerse a las reglas anteriores, pero recuerde que cualquier cosa anterior a PHP 5.6 ahora no es compatible.

Ver: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Si te importa XSS, entonces debes usar la <?= htmlspecialchars(…) ?>mayor parte del tiempo, por lo que una etiqueta corta no hace una gran diferencia.

Incluso si acorta echo htmlspecialchars()a h(), sigue siendo un problema que hay que recordar que añadir que casi todas las veces (y tratando de no perder los datos que se pre-escapó, que es sin escapar, pero sólo hace inofensiva-errores más probable).

Utilizo un motor de plantillas que es seguro de forma predeterminada y escribe <?phpetiquetas para mí.

<?php ?>son mucho mejores de usar ya que los desarrolladores de este lenguaje de programación han actualizado masivamente su lenguaje principal. Puede ver la diferencia entre las etiquetas cortas y las etiquetas largas.

Las etiquetas cortas se resaltarán en rojo claro, mientras que las más largas se resaltarán más oscuras.

Sin embargo, hacer eco de algo, por ejemplo: <?=$variable;?>está bien. Pero prefiero las etiquetas más largas.<?php echo $variable;?>

Convierta <?(sin un espacio final) a <?php(con un espacio final):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

Convierta <?(con un espacio final) a <?php(reteniendo el espacio final):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'

La etiqueta corta siempre está disponible en php. Por lo tanto, no necesita hacer eco de la primera declaración en su secuencia de comandos

ejemplo:

    $a =10;
    <?= $a;//10 
    echo "Hellow";//
    echo "Hellow";

   ?>

De repente, debe usarlo para un solo script php, luego puede usarlo. ejemplo:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>

A partir de 2019, no estoy de acuerdo con ciertas respuestas aquí. Recomiendo usar etiquetas largas

<?php /* code goes here */ ?>

o etiquetas de eco cortas

<?= /* code goes here */ ?>

Motivo: son recomendados por el estándar de codificación básica PSR-1

No <? /* code goes here */ ?>se recomiendan otras etiquetas cortas como .

La especificación dice:

El código PHP DEBE usar las etiquetas largas o las etiquetas de eco corto; NO DEBE usar las otras variaciones de etiqueta .

Hay 3 etiquetas disponibles en php:

1. etiqueta de formato largo que <?php ?>no necesita dirigir ninguna configuración
2. short_open_tag que está <? ?> disponible si la opción short_open_tag en php.ini está activada
3. acortar etiqueta <?= desde php 5.4.0 siempre está disponible

de php 7.0.0 asp y la etiqueta de script se eliminan

No, y PHP 6 los está eliminando paulatinamente, por lo que si aprecia la longevidad del código, simplemente no los use ni las <% ... %>etiquetas.