inicio fin etiquetas ejemplos cortas php coding-style php-shorttags

etiquetas - inicio y fin en php



¿Las etiquetas cortas de PHP son aceptables para usar? (25)

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 esos, <?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 de estilo ASP, son menos portátiles y, en general, no se recomiendan .

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

<?=

es mucho más conveniente que escribir

<?php echo

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

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

Por lo tanto, el acceso directo de eco en sí ( <?= ) Es seguro de usar ahora.

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

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

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

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

Debido a la confusión que puede generar con declaraciones XML. Sin embargo, muchas personas agree contigo.

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

El problema con todo este debate radica en el uso de PHP como un lenguaje de plantillas. Nadie está argumentando 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 potente lenguaje de plantilla, y las plantillas deben ser lo más simples y legibles posible. A muchos les resulta más fácil utilizar un motor de plantillas de complemento mucho más lento, como Smarty, pero para aquellos puristas entre nosotros que exigen una representación rápida y una base de código puro, 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 los conflictos con los documentos XML son ridículos, porque probablemente no debería 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 lo que respecta al problema del soporte del servidor, hay que tener en cuenta que su plataforma de destino debe ser consciente. Si el alojamiento compartido es un objetivo probable, deben evitarse las etiquetas cortas. Pero para muchos desarrolladores profesionales (como yo), el cliente reconoce (y de hecho, depende del hecho) que estaremos dictando 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é el 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 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 esté consciente de su entorno debería sentirse libre de usarlos.

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

Así que parece que las etiquetas cortas son (a) aceptables y (b) para quedarse. Por ahora al menos...

En mi humilde opinión, las personas que usan etiquetas cortas a menudo olvidan escapar de lo que sea que están haciendo eco. Sería bueno tener un motor de plantilla que se escape de forma predeterminada. 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 ser Smarty una mejor opción?

{$myString|escape}

para mí eso se ve mejor que

<?= htmlspecialchars($myString) ?>

Es bueno usarlos cuando trabajas con un framework MVC o CMS que tiene archivos de visualización separados.
Es rápido, menos código, no confuso para los diseñadores. Solo asegúrese de que la configuración de su servidor permita su uso.

Las etiquetas cortas están regresando gracias a Zend Framework que presiona " PHP como lenguaje de plantilla " en su configuración MVC predeterminada . No veo de qué 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.

ACTUALIZAR

Después de hacer un poco de trabajo con Magento , que utiliza 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.

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 otra cosa cuando están claramente para PHP? <% y%> significa ASP para mí, y <script ..... significa Javascript (en la mayoría de los casos). Entonces, para la coherencia, el aprendizaje rápido, la portabilidad y la simplicidad, ¿por qué no atenerse a la norma?

Por otro lado, estoy de acuerdo en que las etiquetas cortas en las plantillas (y SOLO en las plantillas) parecen ser útiles, pero el problema es que hemos pasado tanto tiempo discutiendo aquí, que probablemente llevaría mucho tiempo perder el tiempo. ¡Mucho tiempo escribiendo los tres caracteres extra de "php"!

Si bien tener muchas opciones es bueno, no es en absoluto 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 no es flexible en muchos otros aspectos: genera avisos o errores sobre la menor inconsistencia, pero 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é es lo que está mal, ya que en algunos casos no se da 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 debería permitir <? Php y?> Solo para mantener todo consistente y portátil. Para este último, el método <? = $ Var?> Es feo. ¿Por qué debe ser así? ¿Por qué no añadir 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 ese 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 etiquetas de apertura y cierre y la adición aleatoria de una etiqueta especial "eco", PHP también puede tener un indicador de "etiquetas de apertura / cierre personalizadas" en php.ini o .htaccess. De esa manera los diseñadores pueden elegir el que más les guste. Pero por razones obvias eso es una exageración. Entonces, ¿por qué permitir 4+ opciones?

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, muchos hosts compartidos soportan shorttags pero "lotes" no lo son todos. Si desea compartir sus scripts, es mejor usar la sintaxis completa.

Estoy de acuerdo en que <? y <?= son más fáciles para los programadores que <?php y <?php echo pero es posible realizar una búsqueda y reemplazo masivos siempre que use la misma forma cada vez (y no coloque espacios en el espacio) (por ejemplo, : <? php o <? = )

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 en PHP 5.4+. Si desea admitir la versión anterior a la 5.4 y no puede garantizar las etiquetas de acceso breve, deberá utilizar <?php echo ... ?> .

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

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

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

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

  • Etiquetas cortas de PHP <? … ?> <? … ?> Se han ido
  • Desde PHP 5.4, las etiquetas de impresión corta <?=… ?> Siempre están habilitadas, independientemente de la configuración de short_open_tag .

Buen viaje al primero, ya que interfirió con otros idiomas.

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

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

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

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

Si te importa XSS , deberías usar <?= htmlspecialchars(…) ?> mayoría del tiempo, por lo que una etiqueta corta no hace una gran diferencia.

Incluso si acortas echo htmlspecialchars() a h() , sigue siendo un problema que debes recordar para agregarlo casi todas las veces (y tratar de mantener un registro de los datos que se escapan previamente, lo que no deja escapar, pero es inofensivo) errores más probables).

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

Soy demasiado aficionado a <?=$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 las raras ocasiones en que están apagados. El otro 15% utiliza proveedores de alojamiento principal, y prácticamente todos ellos tienen habilitados. Los amo

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 difícil 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 planeas ejecutar el código en otro lugar, entonces úsalos si quieres. Prefiero no tener que hacer una búsqueda masiva y reemplazar cuando me doy cuenta de que fue una idea tonta.

Uno tiene que preguntar 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. Usted 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 escriben esos 7 caracteres aquí y allá durante la duración del script?

En comparación con la posibilidad de que algunos de los scripts principales, 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 archivo / servidor ini deja de funcionar, otras posibilidades.

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

Mas facil de leer

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

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

Evaluación de riesgos
Problema = el sitio completo o los scripts principales no funcionan;

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

Conclusión

Ahorras unos segundos aquí y allá, no teniendo que escribir algunos caracteres, pero arriesgas mucho por ello y, como resultado, es probable que pierdas la legibilidad.

Los codificadores front-end o back-end familiarizados con <?= Son más propensos a entender <?php echo , ya que son elementos estándar de PHP - estándar <?php open tag y muy conocido "echo".
(Incluso los codificadores front-end deberían saber "eco" o simplemente no estarán trabajando en ningún código servido por un marco).

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

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

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

y

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

y

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

<?php ?>son mucho mejores para 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 largas.

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

Sin embargo, repitiendo 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.

  • Las etiquetas cortas son aceptables para su uso en los casos en 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.
  • 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 de estilo asp estandarizadas alternativas, como <% lugar de <? , que es una configuración en php.ini llamada asp_tags. Aquí está su razonamiento:

... las convenciones arbitrarias deben ser estandarizadas . Es decir, cada vez que nos enfrentamos a un conjunto de posibilidades que son todas de igual valor, como la extraña puntuación que nuestro lenguaje de programación debería usar para demarcarse a sí mismo, deberíamos elegir una forma estándar y seguirla. De esa manera, reducimos la curva de aprendizaje de todos los idiomas (o lo que sea que pertenezca a la convención).

Me parece bien, pero no creo que ninguno de nosotros pueda rodear los vagones alrededor de esta causa. Mientras tanto, me quedaría con el <?php .

  • 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 cambiarse 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, especialmente si está atascado con una base de código con HTML y PHP estrechamente entrelazados.