¿Es aceptable el uso de etiquetas cortas de PHP?
Aquí está la información según 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>, están siempre 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, si bien algunas personas encuentran convenientes las etiquetas cortas y las etiquetas de estilo ASP, son menos portátiles y, en general, no se recomiendan .
En mi experiencia, la mayoría de los servidores tienen habilitadas etiquetas cortas. Mecanografía
<?=
es mucho más conveniente que escribir
<?php echo
La comodidad de los programadores es un factor importante, entonces ¿ por qué no se recomiendan?
Debe haber una distinción clara entre la etiqueta corta de PHP ( <?) y la etiqueta de eco abreviada ( <?=).
Lo primero está prohibido por el estándar de codificación PHP , principalmente por sentido común porque es un PITA si alguna vez tienes que mover tu código a un servidor donde no es compatible (y no puedes habilitarlo). Como usted dice, muchos hosts compartidos admiten etiquetas cortas, pero "muchos" no son todos. Si desea compartir sus scripts, es mejor utilizar la sintaxis completa.
Mientras que la etiqueta de eco abreviada <?=no se puede desactivar y, por lo tanto, su uso es totalmente aceptable.
Estoy de acuerdo en que <?es más fácil para los programadores, <?phppero es posible realizar una búsqueda y reemplazo masivo siempre que utilice el mismo formulario cada vez.
No creo que la legibilidad sea una razón en absoluto. Los desarrolladores más serios tienen a su disposición la opción de resaltar la sintaxis.
Como menciona ThiefMaster en los comentarios, a partir de PHP 5.4, <?= ... ?>las etiquetas se admiten en todas partes, independientemente de la configuración de shorttags . Esto debería significar que son seguros de usar en código portátil, pero eso significa que luego existe una dependencia de PHP 5.4+. Si desea admitir versiones anteriores a 5.4 y no puede garantizar etiquetas cortas, aún deberá usar <?php echo ... ?>.
Además, debe saber que las etiquetas ASP <%, %>, <%= y la etiqueta 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.
Me gusta demasiado como <?=$whatever?>para dejarlo pasar. 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 las raras ocasiones en que están desactivados. El otro 15% utiliza proveedores de alojamiento convencionales y prácticamente todos los tienen habilitados. Los amo.
A partir de PHP 5.4, el acceso directo de eco es un problema independiente de las etiquetas cortas, ya que el acceso directo de eco siempre estará habilitado. Es un hecho ahora:
- Revisión SVN por Rasmus Lerdorf
- Discusión sobre la lista de correo
<?=Por lo tanto , ahora es seguro utilizar el método abreviado de eco ( ).
El problema con toda esta discusión radica en el uso de PHP como lenguaje de plantillas. Nadie discute que las etiquetas deban usarse en los archivos fuente de la aplicación.
Sin embargo, la sintaxis integrable de PHP permite que se utilice como un potente 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 complementario mucho más lento como Smarty, pero para aquellos puristas entre nosotros que exigen una renderización rápida y una base de código pura, PHP es la única forma de escribir plantillas.
El ÚNICO argumento válido EN CONTRA del 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 utilizar PHP para generar cadenas de texto. La seguridad nunca debería ser un problema, porque si colocas información confidencial, como credenciales de acceso a bases de datos, dentro de archivos de plantilla, ¡entonces tienes problemas mayores!
Ahora bien, en cuanto a la cuestión del soporte del servidor, es cierto que hay que tener en cuenta la 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 nosotros 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 brinde 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.
Así que sí, estoy de acuerdo en que se debe sopesar cuidadosamente el uso de etiquetas cortas. Pero también creo firmemente que SIEMPRE debería ser una opción, y que un desarrollador consciente de su entorno debería sentirse libre de utilizarlos.
Las etiquetas cortas están regresando gracias a que Zend Framework introdujo " 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 funcionará en un servidor que usted o su empresa controlarán. Mientras seas constante, no debería haber ningún problema.
ACTUALIZAR
Después de trabajar bastante con Magento , que utiliza formato largo. Como resultado, cambié a la forma larga de:
<?php and <?php echo
encima
<? and <?=
Parece una pequeña cantidad de trabajo para asegurar la interoperabilidad.
