¿Son aceptables las etiquetas cortas de PHP?


522

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?


61
Para responder a la whyparte, citaría la guía de certificación Zend PHP 5: "Las etiquetas cortas fueron, por un tiempo, el estándar en el mundo PHP; sin embargo, tienen el mayor inconveniente de entrar en conflicto con los encabezados XML y, por lo tanto, tienen algo caído en el camino ".
Fluffy

77
¿Cuál es el caso de uso en el que surge ese problema? ¿Eso significa que es difícil para los desarrolladores generar XML usando PHP?
Jon z

99
Supongamos que tiene documentos XML que desea que sean públicos, pero desea que los documentos sean analizables por php por cualquier motivo, por lo que puede hacer que .xml sea analizable por su navegador. Utiliza etiquetas cortas para que se activen, y de repente el documento XML se analiza a través de los encabezados XML, rompiendo cosas. Me volvió loco tratando de resolver esto hace mucho tiempo. Desde que los códigos cortos se han deshabilitado en cualquier servidor que ejecuto y cualquier equipo con el que he trabajado ha tenido que recurrir a un código no corto
thenetimp

43
¡Desde PHP 5.4.0, la directiva short_open_tag no incluye la etiqueta de eco corta <?= $example;?> ! Esto es muy importante ya que el uso de todas las otras etiquetas cortas se considera inútil. De todos modos, se recomienda el uso de la etiqueta de eco corta de ahora en adelante. Proporciona una base de código más suave y ordenada, especialmente. en ver archivos. Entonces, para PHP> = 5.4.0 <?= ?> se puede usar sin configuración short_open_tag . No use las otras etiquetas cortas en su código. Los dioses del código se enojan mucho cuando lo haces ...
Borislav Sabev

66
Voy a agregar esto como un comentario rápido, porque ya hay demasiadas respuestas largas: <?no solo se usa en XML para la <?xml version="1.0" ?>declaración de apertura ; es la sintaxis general para "instrucciones de procesamiento", siendo el segundo ejemplo más común <?xml-stylesheet ... ?>. <?phpen realidad se puede considerar una instrucción de procesamiento válida, como se puede <?=(como se permite en 5.4+), pero afirmar que todo <?también crea conflictos innecesarios entre las sintaxis.
IMSoP

Respuestas:


374

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.


9191
Entonces, la explicación es: ¿son malos porque no son compatibles? ¿Pero por qué no son compatibles? ¿Porque no son parte de la especificación? Ok, pero ¿por qué no son parte de la especificación? Estoy un poco decepcionado con esta respuesta.
Josef Sábl el

61
No estoy aquí para discutir las "grandes preguntas", como por qué estamos aquí, cómo comenzó todo, etc. El soporte de Shorttag no está garantizado en servidores compartidos y se eliminará por completo en la próxima versión principal. Esto es todo lo que necesitas saber.
Oli

39
PHP obligatorio es un motor de plantillas. : P
Error de sintaxis el

49
Las etiquetas cortas no se están eliminando gradualmente. Solo etiquetas cortas de estilo ASP.
Brian Lacy

46
En el futuro (muy cercano) de PHP 5.4, el uso de <? = Se separará de si short_open_tags están habilitados o deshabilitados. <? = no se está eliminando, sino todo lo contrario, ahora se considera una pieza fundamental del lenguaje.
Sr. Griever

176

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


41
@B Seven Si intenta evitar todos los problemas teóricos que puedan surgir, su código será definitivamente ineficiente y tendrá errores. Hasta que el grupo PHP acepte eliminar las etiquetas cortas [no las etiquetas ASP], la preocupación de ser mordido es mucho menor, y la solución potencial es mucho más simple, que otras cosas en las que puede pasar su tiempo "reparando".
SamGoody

18
si te muerde, muévete a un mejor hosting
Lie Ryan

44
Realmente no estoy de acuerdo con no usar algo porque podría no ser compatible. ¿No deberíamos usar ninguna de las otras funciones que podrían no ser compatibles con un servidor? MYSQL vs MYSQLI? Perderás tu tiempo poco a poco, una y otra vez escribiendo etiquetas largas solo para evitar una pequeña posibilidad de pasar un poco de tiempo para cambiar a un mejor host.
Dean o

2
@BSeven, ¿Quieres decir que no usas ninguna extensión de PHP excepto las enviadas por defecto?
Pacerier

143

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:

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


19
Yo diría que esta es la única "etiqueta corta" necesaria. <?phppuede usarse al comienzo de todos los archivos de clase, y luego tiene <?=para sus vistas. ganar-ganar
Xeoncross

66
So the echo shortcut itself (<?=) is safe to use... siempre y cuando se sienta cómodo requiriendo PHP 5.4. Las aplicaciones PHP ampliamente distribuidas (como WordPress) no tienen el lujo de requerir 5.4, e incluso continuaron ofreciendo soporte PHP 4 hasta 2011, 7 años después del lanzamiento de PHP 5. Si está en un lugar como Facebook, donde todas las instalaciones de su software son operadas directamente por la propia empresa, entonces requerir soporte 5.4 es mucho más fácil que si está trabajando en un proyecto como WordPress.
Frank Farmer

@dukeofgaming, Vaya buena captura, no sabía que sus revisiones SVN son accesibles en la web.
Pacerier

82

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.


66
Si, por alguna razón, tuviera configurado Apache para pasar archivos .xml a mod_php, lo de <? Xml sería un dolor de cabeza con etiquetas cortas. Pero eso es obviamente una configuración extraña.
Frank Farmer

3
Un lenguaje de plantillas que no se puede incrustar sin soluciones en algunos tipos de documentos de salida es un gran error. La única razón por la que no debería tener una plantilla XML con código PHP y etiquetas cortas es porque no funciona, no porque no tenga sentido.
Vinko Vrsalovic

8
No es un "gran fracaso" aprovechar los beneficios de PHP como un lenguaje de plantillas rápido y conveniente. Como dije antes, se trata de sopesar los beneficios y los inconvenientes y escribir el código de una manera que se adapte a su enfoque elegido. No descarte categóricamente un enfoque válido solo porque no funciona en un escenario particular (que puede solucionarse fácilmente).
Brian Lacy el

55
No estoy descartando categóricamente ningún enfoque válido (vea mi respuesta a la pregunta). Usted es el que descarta categóricamente PHP en XML, cito: "no debería mezclar PHP y XML de todos modos". Además, la gran falla a la que me refería era la decisión de usar <?como etiqueta corta, ya que conduce a soluciones feas en XML. Dicho esto, estoy de acuerdo en que se trata de sopesar los beneficios y los inconvenientes, y que si sabes lo que estás haciendo, ciertamente puedes hacerlo. Pero esto no es <?una buena elección.
Vinko Vrsalovic

3
Llego un poco tarde a la fiesta, pero realmente me gusta esta respuesta, y refleja mi experiencia con la situación. Si bien tenemos cierto desacuerdo sobre el tema en nuestra oficina, puedo decir que con el trabajo casi diario en PHP durante muchos años, nunca me he encontrado con esto como un problema. Cuando PHP se usa para generar XML, en mi experiencia siempre ha estado en el contexto de contenido altamente dinámico, que nunca fue directamente creado a través de PHP, por lo que el problema nunca surge.
redreinard

33

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.


8
Independiente y todo mi código va al alojamiento compartido, ¡así que no tengo ningún control! :)
MDCore

12
Si tiene suficientes clientes que se mudan a su propio coloc, el alojamiento compartido es inseguro e inestable.
Jake McGraw el

2
Las etiquetas cortas que Zend estaba trayendo aparentemente no se entendieron ya que Zend está usando la versión larga: framework.zend.com/manual/en/zend.view.scripts.html
Gerry

3
@Gerry También he leído esto recientemente, vea el último comentario en este hilo: Actualice .htaccess para habilitar etiquetas abiertas cortas
MrWhite

2
Realmente debería corregir la gramática en la primera oración después de ACTUALIZAR, lo que no tiene sentido en su forma actual.
redreinard

22

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 ...


¿La declaración XML no causará confusión de todos modos si short_tags está activado?
MDCore

Entonces, en lugar de generar directamente la declaración XML, tiene PHP echo. No es realmente una buena refutación.
MOO

No es una refutación de nada. Es la única razón real que a su vez es la causa de la otra razón por la que "Hoster lo apaga", por supuesto, puede usarlo si sabe lo que está haciendo, como siempre.
Vinko Vrsalovic

1
@ Macek: Soy consciente de eso. Fue solo el primer ejemplo en el que pensé. Otro, ¿qué pasa si incrusta PHP en un archivo XML? No puedes hacer eso directamente. Y no me digas la solución a ese problema también, soy consciente de ellos. El punto es que hay muchas formas para que PHP analice un archivo XML. Probablemente pueda descartarlos a todos con soluciones ( <?='<?xml') o diciendo "no debe hacer eso", pero eso no hace que el hecho de que pueda suceder desaparezca.
Vinko Vrsalovic 29/10/10

1
¿Cómo es que las etiquetas cortas son un dolor si no funcionan? su es muy fácil de hacer un mayor y reemplazar <?=con <? echo . muchos editores de texto pueden manejar fácilmente esto para miles de archivos a la vez.
Yamiko

20

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

árbol de toma de decisiones del uso de <? =

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


2
Esto describe si se debe usar la etiqueta de eco corta, no lo mismo que las <?etiquetas cortas mencionadas en la pregunta (aunque usó la misma configuración de configuración anterior a 5.4)
Alok

De hecho, esta debería ser una respuesta que todos puedan entender, aunque las circunstancias no se explican realmente por qué no desea utilizar etiquetas cortas en muchos casos (por ejemplo, no puede cambiar el archivo php.ini en un sistema de alojamiento compartido)
Björn K

14

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.


14

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...


55
<?=no se considera una etiqueta corta a partir del 5.4
T0xicCode

12
  • 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.


2
Las etiquetas cortas están habilitadas en el 95% de los servidores web.
Paolo Bergantino

19
No compro el argumento de "legibilidad". Si está utilizando PHP como lenguaje de plantillas, <?= $var ?>es mucho más legible que<?php echo $var ?>
Frank Farmer

2
@Paulo esto puede haber cambiado desde '08, pero las instancias EC2 de Ubuntu y Fedora con yum install y apt-get versiones de PHP tienen el etiquetado corto deshabilitado por defecto
Doug Molineux

2
use etiquetas completas y tendrá 100% :)
Elvis Ciotti

1
@FrankFarmer, creo que está comparando el que no tiene eco. <?vs <?php.
Pacerier

11

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


5

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?


4

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.


4

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.



3

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) ?> 

10
Para la mayoría de los programadores de PHP, la segunda opción tiene más sentido que la primera, simplemente porque es una función PHP real con la que estamos familiarizados, mientras que la primera opción es el código de pseudo-plantilla que tenemos que aprender sobre PHP. PHP ya es un lenguaje de plantillas, agregando otro lenguaje de plantillas como Smarty es una OMI redundante.
Bug Magnet

3
Twig es un motor de plantillas con escape HTML habilitado por defecto twig.sensiolabs.org
mateusza

3

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".


No tiene nada que ver con escribir. Es más corto y, por lo tanto, tiene el potencial de ser más fácil de leer . Una persona acostumbrada a leer <?=leerá <?=más fácilmente que una persona acostumbrada a <?php echoleer <?php echo.
Pacerier

@Pacerier Shorter no es simplemente = más fácil de leer. Todos somos diferentes. Lo que quieres decir es que es más fácil de leer para ti . Como dije en mi respuesta, como estoy acostumbrado a <?phpver que a través del código muchas veces me resulta más familiar que <?=- la familiaridad hace las cosas más fáciles - aunque no necesariamente mejor.
James

No, no te estoy comparando a ti y a mí, estoy diciendo que una persona acostumbrada a leer <?=leerá <?=mejor que una persona acostumbrada a leer <?php echoleer <?php echo. Eso significa que si tenemos dos copias idénticas de la persona X, y las modificamos solo en el aspecto por el cual una está acostumbrada a leer <?=, y la otra está acostumbrada a leer <?php echo, la primera copia puede alcanzar el valor de legibilidad xmientras lee usando la sintaxis deseada, mientras que la segunda copia puede lograr un valor de legibilidad yal leer la sintaxis deseada, donde x >= y.
Pacerier

No, te estás perdiendo el punto. Me refiero al potencial del sistema, que no tiene nada que ver con ninguna persona en particular. Puede decir que las personas acostumbradas a escribir con el teclado qwerty escribirán más rápido con qwerty, mientras que las personas acostumbradas a escribir con dvorak escribirán más rápido con dvorak, pero el hecho no cambia que los dos sistemas tienen un potencial diferente.
Pacerier

3

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

3
Falso. A veces, el servidor está configurado para negar cualquier tipo de anulación, señor.
Alfabravo

17
Es cierto, pero si su host no le permite anular con htaccess, ¡realmente necesita un nuevo host! :)
Brian Lacy

1
no funciona en la interfaz de línea de comandos, y php_flag no es compatible todo el tiempo
Elvis Ciotti

3

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.


2
  • 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.


2

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


1
A menos que me equivoque, su primer punto es incorrecto. El documento dice que las etiquetas ASP, no las etiquetas PHP cortas, desaparecieron a partir de PHP 7.0.0.
reformado el

@reformed Tienes toda la razón. Editaré mi respuesta. Gracias
Manngo

1

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í.


77
Si se encuentra escribiendo "<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 veces al día, es posible que desee crear una función de acceso directo llamada" h "como Rails ha .." < ? = h ($ text)?> "es mucho más legible al escanear una plantilla.
Alexander Malfait

1
De hecho, es mejor, pero con un motor de plantillas puede ser simplemente $ {text} o algo así (y no tiene que acordarse de agregar h ())
Kornel

77
PHP en sí es un motor de plantillas. Cuando deja de usar etiquetas cortas, comienza a ser un mal motor de plantillas, ya que se vuelve demasiado detallado.
Josef Sábl

1
@Alexander Malfait es un buen consejo. Pero el <? = No es necesario. Puede simplemente hacer que la función haga eco de la cadena en lugar de volver, para que escriba <? Php h ('hello')?> ¿Ya no lo hacemos cuando dei18n? <? php _e ('')?> no es tan malo.
VladFr

1

<?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;?>


1

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'

1

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>

1

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 .


1

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


Eso no responde la pregunta.
RalfFriedl

-5

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.


44
He visto otras publicaciones de blog que dicen que no serán desaprobadas, solo las etiquetas cortas de estilo ASP.
MDCore

22
Parece que esta respuesta es incorrecta, de acuerdo con este enlace de la reunión de desarrolladores de PHP: php.net/~derick/…
Charles el

77
¿POR QUÉ son tan malos, por qué? Todo el mundo está tan seguro de sí mismo que son baaaaaad pero nadie dice por qué.
Josef Sábl el

66
FALSO. Están eliminando gradualmente las etiquetas <%%>, como deberían. No tienen otro propósito que confundir. El <? ?> las etiquetas no se verán afectadas; pero, por supuesto, todavía son configurables por servidor, y siempre debe conocer los requisitos de su plataforma de destino.
Brian Lacy

66
Esta información parece ser incorrecta y engañosa, y debe ser corregida por el autor.
tex
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.