¿Son aceptables las etiquetas cortas PHP?

Soy demasiado aficionado a <?=$whatever?> para dejarlo ir. Nunca tuve un problema con eso. Esperaré hasta que me muerda en el culo. En serio, el 85% de (mis) clientes tienen acceso a php.ini en la rara ocasión se apagan. El otro 15% utiliza proveedores de alojamiento convencionales, y prácticamente todos ellos los tienen habilitados. Me encantan.

A partir de PHP 5.4, el acceso directo de echo es un problema separado de las etiquetas cortas, ya que el acceso directo de echo siempre estará habilitado. Es un hecho ahora:

• SVN Revision by Rasmus Lerdorf
• Discusión de la lista de correo

Así que el atajo de echo en sí (<?=) es seguro de usar ahora.

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

Sin embargo, la sintaxis incrustable de PHP permite que se use como un poderoso lenguaje de plantillas, y las plantillas deben ser lo más simples y legibles posible. Muchos han encontrado más fácil usar un motor de plantillas mucho más lento como Smarty, pero para aquellos puristas entre nosotros que exigen un renderizado rápido y una base de código pura, PHP es la única manera 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ía mezclar PHP y XML de todos modos; y si lo está, debería usar PHP para generar cadenas de texto. La seguridad nunca debería ser un problema, porque si está poniendo información confidencial como las credenciales de acceso a la base de datos dentro de los archivos de plantilla, grandes problemas!

Ahora bien, en cuanto a la cuestión del soporte del servidor, es cierto que uno tiene que ser consciente de su plataforma de destino. Si el alojamiento compartido es un objetivo probable, 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 hosting que no nos da control absoluto de la configuración del servidor -- en tal caso podríamos contar con correr a muchos más problemas que simplemente perder el soporte de etiquetas cortas. Simplemente no sucede.

Así que sí agree estoy de acuerdo en que el uso de etiquetas cortas debe ser cuidadosamente sopesado. Pero también creo firmemente que siempre debe ser una opción, y que un desarrollador que es consciente de su entorno debe sentirse libre de usarlos.

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

UPDATE

Después de hacer bastante trabajo con Magento, que utiliza forma larga. Como resultado, he cambiado a la forma larga de:

<?php and <?php echo

Sobre

<? and <?=

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

Debido a la confusión que puede generar con las 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 las tiene desactivadas...

Lo siguiente es el maravilloso diagrama de flujo de la misma:

Fuente: pregunta similar sobre la Ingeniería de Software Stack Exchange

Http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php tiene muchos consejos, incluyendo:

Mientras que algunas personas encuentran etiquetas cortas y Etiquetas de estilo ASP convenientes, son menos portátil, y generalmente no recomendar.

Y

Tenga en cuenta que si está incrustando PHP dentro de XML o XHTML tendrá que utilice las etiquetas <?php ?> para permanecer cumple con los estándares.

Y

El uso de etiquetas cortas debe ser evitar al desarrollar aplicaciones o bibliotecas destinadas a redistribución, o implementación en PHP servidores que no están bajo su control, porque las etiquetas cortas pueden no ser compatible con el servidor de destino. Para código portable, redistribuible, be asegúrate 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 <?= está siempre disponible:

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

Así que parece que las etiquetas cortas son (a) aceptables y (b) están aquí para quedarse. Al menos por ahora...

• 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 moverse a uno de estos.

• La Legibilidad puede ser un problema para algunos. Muchos desarrolladores pueden encontrar que <?php llama 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 entretejido.

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 un tema importante no se ha mencionado: pereza vs.consistencia. Las etiquetas "reales" para PHP son . ¿Por qué? Realmente no me importa. ¿Por qué querrías usar algo más cuando esos son claramente para PHP? significan ASP para mí, y

Por otra parte I de acuerdo en que las etiquetas cortas en las plantillas (y SOLO en las plantillas) parecen útiles, pero el problema es que acabamos de pasar tanto tiempo discutiendo aquí, que probablemente tomaría mucho tiempo para haber perdido realmente tanto tiempo escribiendo los tres caracteres adicionales de "php"!!

Si bien tener muchas opciones es bueno, no es del todo lógico y puede causar problemas. Imagine si cada lenguaje de programación permitiera 4 o más tipos de etiquetas: Javascript podría ser

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

En el punto donde hay 4 opciones para etiquetas abiertas y cerradas y la adición aleatoria de una etiqueta especial "echo", PHP también puede tener una bandera "custom open/close tags" en php.ini or .htaccess. De esa manera 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 trabajas con un framework MVC o CMS que tienen archivos de vista separados.
Es rápido, menos código, no confuso para los diseñadores. Solo asegúrese de que la configuración de su servidor permite su uso.

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

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

Puede habilitarlos en un archivo .htaccess si no puede acceder al php.ini:

php_flag short_open_tag on

<? está deshabilitado de forma predeterminada en las versiones más recientes. Puede habilitar esto como se describe Habilitar Etiquetas Cortas en PHP.

En mi Humilde opinión, las personas que usan etiquetas cortas a menudo se olvidan de escapar de lo que están haciendo 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 Smarty podría 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 de escribir

MDCore dijo:

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

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

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

En comparación con el potencial de que algún núcleo, o todos, de sus scripts 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 archivo/servidor ini los detiene, otros potenciales.

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

Más Fácil de leer

Esto depende de la familiaridad.
Siempre he visto y usado <?php echo. Así que mientras <?= no es difícil de leer, no es familiar para mí y por lo tanto no es más fácil de leer.

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

Evaluación del riesgo
Issue = todo el sitio o los scripts del núcleo no funcionan;

El potencial del 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 unos cuantos caracteres, pero arriesgas mucho por ello, y también probablemente pierda legibilidad como resultado.

Los codificadores Front o back end familiares con <?= son más propensos a entender <?php echo, ya que son cosas estándar de PHP - estándar <?php etiqueta abierta y muy conocido "echo".
(Incluso los codificadores front end deben 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".

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

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

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

... las convenciones arbitrarias deben ser estandarizado. Es decir, cada vez que estamos frente a un conjunto de posibilidades que son todos de igual valor-como lo que puntuación extraña nuestra programación el lenguaje debe usarse para demarcar sí mismo-debemos elegir un estándar forma y seguir con ella. De esa manera reducir la curva de aprendizaje de todos idiomas (o lo que sea que las cosas la convención se refiere a).

Suena bien para mí, pero no creo que ninguno de nosotros pueda rodear los carros alrededor de esta causa. Mientras tanto, me gustaría atenerme a la completa <?php.

Convertir <? (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'

Convertir <? (con un espacio final) a <?php (conservando el espacio final):

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

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

• Las etiquetas PHP cortas <? … ?> se han ido
• Desde PHP 5.4, las etiquetas cortas Print <?=… ?> están siempre habilitadas, independientemente de la configuración short_open_tag.

Adiós al primero, ya que interfirió con otros idiomas.

Ahora no hay razón para no usar las etiquetas de impresión corta, aparte de la preferencia personal.

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

Véase: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Si te importa XSS entonces deberías usar <?= htmlspecialchars(…) ?> la 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 debe recordar agregarlo casi siempre (y tratar de realizar un seguimiento de qué datos se escapan previamente, lo que no se escapa, pero es inofensivo, solo hace que los errores sean más probables).

Utilizo un motor de plantillas que es seguro por defecto y escribe etiquetas <?php para mí.

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

Las etiquetas cortas se resaltarán como 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;?>

No, y están siendo eliminados por PHP 6 así que si aprecias la longevidad del código, simplemente no los uses ni las etiquetas <% ... %>.