Perché avere <? Php e?> Su ogni riga


24

Ho visto questa convenzione praticamente dappertutto e, a volte, si avvicina a farmi impazzire:

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

Dove il <?phpe la chiusura ?>sono su ogni singola riga, anche se non vi è alcun codice HTML intermedio.

La mia domanda è: perché? Perché includere tutti questi tag extra?

A me sembra che questa convenzione aggiunga una quantità significativa di disordine al codice, è fastidioso da seguire in primo luogo e aggiunge che molti altri posti per lasciare accidentalmente un tag di apertura o chiusura.

NOTA

Questo è il codice estratto dal tema Twenty-Twelve, l'esempio fornito da WordPress.


inoltre, abbreviazione while dichiarazioni = o
Tom J Nowell

3
Contrassegnare per chiudere - non esiste una risposta definitiva a questa domanda, e certamente non si tratta di un problema specifico del WP - qualsiasi persona che lavora con PHP affronterà questo problema
anu

3
@anu: in primo luogo, una domanda potrebbe non avere sempre una risposta unica e definitiva (anche se potrebbe comunque avere una risposta migliore). Le linee guida dicono "pratiche e rispondenti". In secondo luogo, sì, questo è tecnicamente un problema di PHP, ma ho visto molto, molto di più nel mio breve periodo di lavoro con WP. Quindi, sebbene ciò non sia limitato a WP, mi sembra abbastanza correlato da chiedere in un ambiente WP.
Indigenuità

Risposte:


20

Questo non è raccomandato in nessuna guida di stile di WordPress e penso che sia un cattivo stile di codifica. I principianti usano questo stile, forse perché sembra più un HTML ...

Sfortunatamente, i temi predefiniti usano questo stile troppo spesso, quindi alcuni principianti potrebbero pensare che faccia parte di uno stile di codice.

Uno svantaggio di questo stile è la gestione dei commenti. Guarda da vicino il seguente esempio e come non fa ciò che l'autore potrebbe aspettarsi:

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

Buona fortuna debug. :)

Regola: passa dal contesto PHP a quello HTML solo se devi creare un output in entrambe le lingue. Usa interruzioni di linea regolari in tutti gli altri casi.

Aggiornamento, ulteriori considerazioni: ogni file HTML valido è un programma PHP completo e valido. Sì, anche se non contiene una sola riga del codice PHP effettivo.

Se inizi da HTML e aggiungi piccoli pezzi di PHP passo dopo passo ... potresti finire con lo stile di cui stiamo discutendo qui. È qui che entra in gioco il refactoring : una volta che tutto funziona come previsto, riscrivi il codice fino a quando è il più leggibile possibile, facile da mantenere ed estendere, senza ripetere le parti.

Immagino che alcune persone siano felici senza questo ultimo passo, ed è per questo che questo non morirà presto.


È un peccato che l'evidenziazione della sintassi sopra non mostri cosa effettivamente accade con quel commento ...
webaware

9
@webaware Penso che questo illustri ancora di più il problema. :)
fuxia

Vero :) (oltre ad alcuni caratteri per rendere felice la polizia dei commenti SE)
webaware

2
@AndyAdams Abbastanza giusto, l'ho riformulato. E ora vai via, malvagio consigliere. :)
fuxia

3
I temi usano questo stile perché fare altrimenti è semplicemente troppo brutto. Nel refactoring dei temi, preferirei riscrivere il codice in modo che sia il più leggibile possibile, e ciò significa non avere echo / printf / var_dump tutt'intorno e mettere ogni struttura di controllo all'interno delle proprie coppie <? ... ?>per rendere più semplice la nidificazione. Una cosa che farei diversamente dall'esempio del PO, però, è che avrei messo la the_post();sua linea.
Sdraiati Ryan il

12

Mentre evito questo per i commenti PHP, sono un avido apri / chiudi PHP nei file modello. L'alternativa prevede l'eco dell'HTML tramite stringhe PHP, che secondo me sembra anche peggiore. Come esempio 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>

L'esempio 2 è più dettagliato? Forse? Ma più facile da leggere e modificare, secondo me. Puoi immaginare quanto brutto possa arrivare per HTML complesso.

Inoltre, proprio come nota a margine: l'utilizzo endforeache endifdurante la scrittura di codice HTML tra il PHP migliora la leggibilità di logica una tonnellata rispetto a }.


5
l'enorme vantaggio di }over endifè che (in molti editor) puoi facilmente vedere dove si trova l'apertura {e quindi se tutto è stato correttamente chiuso. Prova a capirlo con endifun sacco di condizionali ...

2
foreach ( $list_items as $list_item ) printf( '<li><a href="%1$s">%2$s</a></li>', $list_item->url, $list_item->name );- due righe, HTML e PHP ben separate. : P
fuxia

4
@toscho: hai completamente perso il punto. Stai ancora mescolando PHP e HTML, le persone che preferiscono il secondo stile lo fanno perché vogliamo evitare di avere HTML all'interno della stringa PHP. Uso il secondo stile quando utilizzo PHP come linguaggio di template perché è l'unico modo per nidificare in modo sensato una combinazione di PHP e HTML, mentre uso il primo quando utilizzo PHP come linguaggio di scripting perché di solito non c'è una buona ragione per avere HTML nello script quando si separa la logica dell'applicazione dal modello. Il secondo stile sarebbe ancora migliore se fossero disponibili tag brevi: <? ... ?>e <?= ... ?>.
Sdraiati Ryan il

1
@Piet: se hai problemi di abbinamento tra parentesi graffe, probabilmente non hai mai sentito parlare di rientro? Inoltre, dovresti essere in grado di configurare per evidenziare l'apertura di endifqualsiasi editor decente.
Sdraiati Ryan il

4
@LieRyan Sii gentile.
Rarst

10

Si tratta di scegliere tra vedere la pagina come:

  • come entità completamente generata da PHP
  • come modello di documento HTML, basato su tag modello PHP

Diverse persone tendono a pensarci diversamente. Nota che le funzioni usano raramente questo stile, perché sembrano più blocchi di puro PHP. D'altra parte non è raro nei modelli perché sono più distribuiti tra i file e la quantità di puro HTML può essere facilmente superiore a quella di PHP in essi.

Se guardi i motori di template (Moustache, Twig, ecc.) - assomigliano molto a questo stile, tranne per il fatto che la loro sintassi tende ad eliminare la verbosità del semplice PHP.

PS Voglio notare che sto parlando di un sano incorporamento di PHP in HTML, non letteralmente di aprire e terminare tag su ogni riga solo per il gusto di farlo.


2

La mia domanda è: perché? Perché includere tutti questi tag extra?

La risposta è piuttosto semplice: pubblico. Quando le persone (non i programmatori) prendono un tema, quindi eseguono il FTPing della loro installazione, eseguendo il programma di installazione di 5 minuti e così via già si sente come programmarli. Quando poi vogliono aggiungere o modificare una singola riga di qualunque cosa nel loro tema, forse hanno già capito che cos'è l'HTML. PHP sarà ancora lontano dalla loro portata. Quindi la mia ipotesi è che l'idea alla base sia quella di consentire una più facile aggiunta o rimozione di elementi senza rompere tutto quando commettono un errore.

Nota: questo non è quello che mi piace, preferisco o consiglierei. È proprio quello che penso perché questo accada.


0

Ho scoperto che alcuni nuovi programmatori sono addestrati in questo modo. Sto seguendo un corso di 40 ore su Lynda e l'istruttore sta rilasciando tag PHP su ogni riga, ad eccezione delle definizioni delle funzioni. È probabilmente per tracciare chiaramente le linee tra HTML e PHP, il che probabilmente aiuta le nuove persone a capire dove finisce HTML e inizia PHP. Dopo ciò, è probabilmente un'abitudine. Stavo iniziando a infastidirmi da solo e ho deciso di vedere se qualcun altro si stava lamentando.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.