¿Por qué tener <? Php y?> En cada línea


24

He visto esta convención prácticamente en todas partes y, a veces, casi me vuelve loco:

<?php //The loop ?>
<?php while ( have_posts() ) : the_post(); ?>
    <?php the_content(); ?>
<?php endwhile; // end of the loop. ?>

Donde el <?phpy el cierre ?>están en cada línea, incluso si no hay código HTML interviniente.

Mi pregunta es: ¿por qué? ¿Por qué incluir todas estas etiquetas adicionales?

Para mí, parece que esta convención agrega una cantidad significativa de desorden al código, es molesto seguirla en primer lugar, y agrega que hay muchos más lugares para omitir accidentalmente una etiqueta de apertura o cierre.

NOTA

Este es un código extraído del tema Twenty-Twelve, el ejemplo dado por WordPress.


también, taquigrafía mientras declaraciones = o
Tom J Nowell

3
Cómo marcar con el cierre - no hay una respuesta definitiva a esta pregunta, y sin duda no es una cuestión específica WP - cualquier persona que trabaja con PHP se enfrentará a este problema
anu

3
@anu: Primero, una pregunta puede no siempre tener una respuesta única y definitiva (aunque todavía puede tener una mejor respuesta). Las pautas dicen "práctico y responsable". Segundo, sí, esto es técnicamente un problema de PHP, pero he visto mucho, mucho más en mi poco tiempo trabajando con WP. Entonces, si bien esto no se limita a WP, me parece que está lo suficientemente correlacionado como para preguntar en una configuración de WP.
Indigenuidad

Respuestas:


20

Esto no se recomienda en ninguna guía de estilo de WordPress, y creo que es un mal estilo de codificación. Los principiantes están usando este estilo, tal vez porque se siente más como HTML ...

Desafortunadamente, los temas predeterminados usan este estilo con demasiada frecuencia, por lo que algunos principiantes pueden pensar que es parte de un estilo de código.

Una desventaja de este estilo es el manejo de comentarios. Mire detenidamente el siguiente ejemplo y cómo no hace lo que el autor podría esperar:

<?php echo 'Important: '; // announcement ?>
<?php echo ' enter the word '; /* start ?>
<?php echo '<b>password</b>'; /* the end */ ?>

Buena suerte depurando eso. :)

Regla: Cambie entre el contexto PHP y HTML solo si tiene que crear resultados en ambos idiomas. Use saltos de línea regulares en todos los demás casos.

Actualización, reflexiones adicionales: cada archivo HTML válido es un programa PHP completo y válido. Sí, incluso si no contiene una sola línea de código PHP real.

Si comienzas desde HTML y agregas pequeñas piezas de PHP paso a paso ... podrías terminar con el estilo que estamos discutiendo aquí. Ahí es donde entra en juego la refactorización : una vez que todo funciona como se esperaba, reescribe el código hasta que sea lo más legible posible, fácil de mantener y ampliar, sin repetir partes.

Supongo que algunas personas son felices sin este último paso, y es por eso que esto no morirá pronto.


Es una pena que el resaltado de sintaxis anterior no muestre lo que realmente sucede con ese comentario ...
webaware

99
@webaware Creo que eso ilustra aún más el problema. :)
fuxia

Es cierto :) (además de algunos caracteres para mantener contento a la policía del comentario SE)
webaware

2
@AndyAdams Bastante justo, lo he reformulado. Y ahora vete, mal recomendado. :)
fuxia

3
Los temas usan este estilo porque hacer lo contrario es demasiado feo. Cuando refactorice los temas, preferiría volver a escribir el código para que sea lo más legible posible, y eso significa no tener echo / printf / var_dump por todas partes y poner cada estructura de control dentro de sus propios pares <? ... ?>para que la anidación sea más fácil de comprender. Sin embargo, una cosa que haría de manera diferente al ejemplo del OP es que pondría the_post();su propia línea.
Lie Ryan

12

Si bien evito esto para los comentarios de PHP, soy un ávido abridor / cerrador de PHP en archivos de plantilla. La alternativa implica hacer eco de HTML a través de cadenas PHP, lo que se ve aún peor en mi opinión. Como un ejemplo primitivo:

<!-- Example 1 -->
<ul>
    <?php
        foreach ( $list_items as $list_item ) {
            echo "<li><a href='" . $list_item->url . "'>" . $list_item->name . "</a></li>";
        }
    ?>
</ul>

<!-- Example 2 -->
<ul>
    <?php foreach ( $list_items as $list_item ) : ?>
        <li>
            <a href="<?php echo $list_item->url; ?>">
                <?php echo $list_item->name; ?>
            </a>
        </li>
    <?php endforeach; ?>
</ul>

¿El ejemplo 2 es más detallado? ¿Quizás? Pero más fácil de leer y editar, en mi opinión. Puedes imaginar lo feo que puede ser para HTML complejo.

Además, solo como nota al margen: el uso endforeachy la endifescritura de HTML entre su lógica PHP mejora la legibilidad en una tonelada en comparación con }.


55
la enorme ventaja de }más endifsin embargo es que (en muchos editores) se puede ver fácilmente que la abertura {es, por lo tanto todo lo que se ha cerrado correctamente. Trate de averiguar que fuera con endify un montón de condicionales ...

2
foreach ( $list_items as $list_item ) printf( '<li><a href="%1$s">%2$s</a></li>', $list_item->url, $list_item->name );- dos líneas, HTML y PHP bien separadas. : P
fuxia

44
@toscho: Te perdiste totalmente el punto. Todavía está mezclando PHP y HTML, las personas que prefieren el segundo estilo lo hacen porque queremos evitar tener HTML dentro de la cadena PHP. Uso el segundo estilo cuando uso PHP como lenguaje de plantillas porque es la única forma de anidar una mezcla de PHP y HTML con sensatez, mientras que uso el primero cuando uso PHP como lenguaje de secuencias de comandos porque generalmente no hay una buena razón para tener HTML en el script cuando separa la lógica de la aplicación de la plantilla. El segundo estilo sería aún mejor si hay etiquetas cortas disponibles: <? ... ?>y <?= ... ?>.
Lie Ryan

1
@Piet: si tiene problemas para unir llaves, ¿probablemente nunca haya oído hablar de la sangría? Además, debe poder configurar para resaltar la apertura de endifcualquier editor decente.
Lie Ryan

44
@LieRyan Sé amable.
Rarst

10

Se trata de elegir entre ver la página como:

  • como entidad completamente generada por PHP
  • como plantilla de documento HTML, con tecnología de etiquetas de plantilla PHP

Diferentes personas tienden a pensarlo de manera diferente. Tenga en cuenta que las funciones rara vez usan este estilo, porque se sienten más como bloques de PHP puro. Por otro lado, no es raro en las plantillas porque están más dispersas en los archivos y la cantidad de HTML puro puede ser fácilmente más que la de PHP en ellas.

Si observa los motores de plantillas (Moustache, Twig, etc.), se parecen mucho a este estilo, excepto que su sintaxis tiende a eliminar la verbosidad de PHP simple.

PD: Quiero señalar que estoy hablando de la incrustación sensata de PHP en HTML, no literalmente de abrir y finalizar etiquetas en cada línea solo por el simple hecho de hacerlo.


2

Mi pregunta es: ¿por qué? ¿Por qué incluir todas estas etiquetas adicionales?

La respuesta es bastante simple: audiencia. Cuando las personas (no los programadores) toman un tema, luego envían por FTP su instalación, ejecutan la configuración de 5 minutos, etc. Cuando luego desean agregar o cambiar una sola línea de lo que sea en su tema, entonces tal vez ya descubrieron qué es HTML. PHP aún estará lejos de su alcance. Entonces, supongo que la idea detrás de esto es permitir agregar o quitar elementos más fácilmente sin romper todo cuando cometen un error.

Nota: Esto no es lo que me gusta, prefiero o recomendaría. Es justo lo que pienso por qué sucede esto.


0

He descubierto que algunos programadores nuevos están entrenados de esta manera. Estoy siguiendo un curso de 40 horas sobre Lynda y el instructor está soltando etiquetas PHP en cada línea, con la excepción de las definiciones de funciones. Probablemente sea dibujar líneas claras entre HTML y PHP, lo que probablemente ayude a las personas nuevas a comprender dónde termina HTML y dónde comienza PHP. Después de eso, probablemente sea un hábito. Estaba empezando a molestarme y decidí ver si alguien más se quejaba.

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.