I tag brevi PHP sono accettabili da usare?

Question

Ecco le informazioni secondo la documentazione ufficiale :

  

Esistono quattro diverse coppie di   apertura e chiusura di tag che possono essere   utilizzato in PHP. Due di questi, <?php ?>   e <script language="php"> </script>,   sono sempre disponibili. Gli altri due   sono tag brevi e tag stile ASP e   può essere attivato e disattivato da   file di configurazione php.ini. Come tale,   mentre alcune persone trovano tag brevi e   Tag stile ASP convenienti, lo sono   meno portatile e generalmente no   consigliato .

Nella mia esperienza, la maggior parte dei server è abilitati i tag brevi. Digitando

<?=

è molto più conveniente della digitazione

<?php echo 

La comodità dei programmatori è un fattore importante, quindi perché non sono raccomandati?

Answer 1

Non sono raccomandati perché è un PITA se devi mai spostare il tuo codice su un server dove non è supportato (e non puoi abilitarlo). Come dici tu, molti host condivisi supportano le scorciatoie ma " lotti " non tutti. Se vuoi condividere i tuoi script, è meglio usare la sintassi completa.

Sono d'accordo che < ;? e <? = sono più facili per i programmatori rispetto a <? php e < ? php echo ma è possibile eseguire una ricerca e sostituzione in blocco purché utilizzi lo stesso modulo ogni volta (e non gettare negli spazi (ad esempio: < ;? php o < ;? = )

Non compro la leggibilità come motivo. Gli sviluppatori più seri hanno la possibilità di evidenziare la sintassi a loro disposizione.

Come menziona ThiefMaster nei commenti, a partire da PHP 5.4, < code> <? = ...? > i tag sono supportati ovunque, indipendentemente dalle impostazioni dei tag . Ciò dovrebbe significare che sono sicuri da usare nel codice portatile, ma ciò significa che esiste una dipendenza da PHP 5.4+. Se desideri supportare la pre-5.4 e non puoi garantire le scorciatoie, dovrai comunque utilizzare <? Php echo ...? & Gt; .

Inoltre, devi sapere che tag ASP < %,% > , <% =, e il tag dello script vengono rimossi da PHP 7 . Quindi, se desideri supportare il codice portatile a lungo termine e desideri passare agli strumenti più moderni, considera di cambiare quelle parti di codice.

Answer 2

Sono troppo affezionato a <? = $ qualunque cosa & > per lasciarlo andare. Non ho mai avuto problemi. Aspetterò fino a quando non mi morde il culo. In tutta serietà, l'85% dei (miei) clienti ha accesso a php.ini nella rara occasione in cui sono disattivati. L'altro 15% utilizza provider di hosting tradizionali e praticamente tutti li hanno abilitati. Li adoro.

Answer 3

A partire da PHP 5.4, il collegamento all'eco è un problema separato dai tag brevi, poiché il collegamento all'eco sarà sempre abilitato. È un dato di fatto ora:

• Revisione SVN di Rasmus Lerdorf
• Discussione sulla mailing list

Quindi il collegamento eco stesso ( <? = ) è sicuro da usare ora.

Answer 4

Il problema di tutta questa discussione risiede nell'uso di PHP come linguaggio esemplare. Nessuno sostiene che i tag debbano essere usati nei file sorgente dell'applicazione.

Tuttavia, la sintassi incorporabile di PHP consente di utilizzarla come un potente linguaggio di template e i template dovrebbero essere il più semplici e leggibili possibile. Molti hanno trovato più facile usare un motore di template aggiuntivo molto più lento, come Smarty, ma per quei puristi tra noi che richiedono un rendering veloce e una base di codice pura, PHP è l'unico modo per scrivere template.

L'UNICO argomento valido CONTRO l'uso di tag brevi è che non sono supportati su tutti i server. I commenti sui conflitti con i documenti XML sono ridicoli, perché probabilmente non dovresti mescolare PHP e XML comunque; e se lo sei, dovresti usare PHP per generare stringhe di testo. La sicurezza non dovrebbe mai essere un problema, perché se stai inserendo informazioni sensibili come le credenziali di accesso al database all'interno dei file modello, beh, allora hai problemi più grandi!

Ora, quindi, per quanto riguarda il problema del supporto del server, bisogna ammettere che bisogna conoscere la propria piattaforma di destinazione. Se l'hosting condiviso è un obiettivo probabile, è necessario evitare tag brevi. Ma per molti sviluppatori professionisti (come me), il client riconosce (e in effetti dipende dal fatto) che detteremo i requisiti del server. Spesso sono responsabile della configurazione del server da solo.

E non lavoriamo MAI con un provider di hosting che non ci dia il controllo assoluto della configurazione del server - in tal caso potremmo contare su problemi molto più che perdere il supporto dei tag brevi. Semplicemente non succede.

Quindi sì - sono d'accordo che l'uso di tag brevi debba essere attentamente valutato. Ma credo fermamente che dovrebbe SEMPRE essere un'opzione e che uno sviluppatore consapevole del suo ambiente dovrebbe sentirsi libero di usarli.

Answer 5

I tag brevi stanno tornando grazie a Zend Framework spingendo il " PHP come linguaggio modello " nella loro configurazione MVC predefinita . Non vedo di cosa parla il dibattito, la maggior parte del software che produrrete durante la vostra vita funzionerà su un server controllato da voi o dalla vostra azienda. Finché ti mantieni coerente, non dovrebbero esserci problemi.

Aggiorna

Dopo aver lavorato parecchio con Magento , che utilizza la forma lunga. Di conseguenza, sono passato alla forma lunga di:

<?php and <?php echo

su

<? and <?=

Sembra una piccola quantità di lavoro per assicurare l'interoperabilità.

Answer 6

Perché la confusione può generare con dichiarazioni XML. Molte persone concordano con tu, comunque.

Un'ulteriore preoccupazione è il dolore che genererebbe per codificare tutto con tag brevi solo per scoprire alla fine che il server di hosting finale li ha disattivati ??...

Answer 7

Di seguito è riportato il meraviglioso diagramma di flusso dello stesso:

Fonte: domanda simile sullo scambio di stack di ingegneria del software

Answer 8

http://uk3.php.net/manual/ it / language.basic-syntax.phpmode.php ha molti consigli, tra cui:

  

mentre alcune persone trovano tag brevi e   Tag stile ASP convenienti, lo sono   meno portatile e generalmente no   consigliato.

e

  

nota che se stai incorporando PHP   all'interno di XML o XHTML dovrai farlo   usa i tag <? php? > per rimanere   conforme alle norme.

e

  

L'uso di tag brevi dovrebbe essere evitato   durante lo sviluppo di applicazioni o   librerie destinate a   ridistribuzione o distribuzione su PHP   server che non sono sotto il tuo   controllo, perché i tag brevi potrebbero non esserlo   supportato sul server di destinazione. Per   codice portatile, ridistribuibile, be   sicuro di non usare tag brevi.

Answer 9

Se qualcuno continua a prestare attenzione a questo ... A partire da PHP 5.4.0 Alpha 1 <? = è sempre disponibile:

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

Quindi sembra che i tag brevi siano (a) accettabili e (b) qui per rimanere. Per ora almeno ...

Answer 10

• I tag brevi non sono attivati ??per impostazione predefinita in alcuni server web (host condivisi, ecc.), quindi portabilità del codice diventa un problema se devi passare a uno di questi.

• Leggibilità potrebbe essere un problema per alcuni. Molti sviluppatori potrebbero scoprire che <? Php attira l'attenzione come un marcatore più evidente dell'inizio di un blocco di codice rispetto a < ;? quando si esegue la scansione di un file, in particolare se sei bloccato con una base di codice con HTML e PHP strettamente intrecciati.

Answer 11

Nota: a partire da PHP 5.4 il tag breve, <? = , è ora sempre disponibile.

Answer 12

Ho letto questa pagina dopo aver cercato informazioni sull'argomento e ritengo che non sia stato menzionato un problema importante: la pigrizia contro la coerenza. Il "reale" i tag per PHP sono <? php e? > ;. Perché? Non mi interessa davvero. Perché vorresti usare qualcos'altro quando questi sono chiaramente per PHP? <% e% > significa ASP per me e < script ..... significa Javascript (nella maggior parte dei casi). Quindi per coerenza, apprendimento veloce, portabilità e semplicità, perché non attenersi allo standard?

D'altra parte concordo sul fatto che i tag brevi nei modelli (e SOLO nei modelli) sembrano utili, ma il problema è che abbiamo appena trascorso così tanto tempo a discuterne qui, che probabilmente ci vorrebbe molto tempo per ho perso tempo a scrivere i tre caratteri in più di " php " !!

Pur avendo molte opzioni è bello, non è affatto logico e può causare problemi. Immagina se ogni linguaggio di programmazione consentisse 4 o più tipi di tag: Javascript potrebbe essere < JS o < script .... o <% o < ;? JS .... sarebbe utile? Nel caso di PHP l'ordine di analisi tende a favorire queste cose, ma la lingua non è flessibile per molti altri aspetti: genera avvisi o errori sulla minima incoerenza, ma spesso vengono usati tag brevi. E quando i tag brevi vengono utilizzati su un server che non li supporta, può richiedere molto tempo per capire cosa è sbagliato poiché in alcuni casi non viene fornito alcun errore.

Infine, non credo che i tag brevi siano il problema qui: ci sono solo due tipi logici di blocchi di codice PHP: 1) codice PHP normale, 2) echi di modello. Per il primo, credo fermamente che solo <? Php e? & Gt; dovrebbe essere consentito solo per mantenere tutto coerente e portatile. Per quest'ultimo, il <? = $ Var? & Gt; il metodo è brutto. Perché deve essere così? Perché non aggiungere qualcosa di molto più logico? <? php $ var? > Ciò non farebbe nulla (e solo nelle possibilità più remote potrebbe entrare in conflitto con qualcosa), e potrebbe facilmente sostituire la sintassi scomoda <?? =. O se questo è un problema, forse potrebbero usare <? Php = $ var? & Gt; invece e non preoccuparti delle incoerenze.

Nel punto in cui ci sono 4 opzioni per i tag di apertura e chiusura e l'aggiunta casuale di uno speciale "eco" tag, PHP può anche avere un tag di apertura / chiusura personalizzato " flag in php.ini o .htaccess. In questo modo i designer possono scegliere quello che preferiscono. Ma per ovvie ragioni è eccessivo. Quindi perché consentire 4+ opzioni?

Answer 13

È utile usarli quando si lavora con un framework MVC o CMS con file di visualizzazione separati.
È veloce, meno codice, non confuso per i progettisti. Assicurati solo che la configurazione del tuo server ne consenta l'utilizzo.

Answer 14

Una situazione leggermente diversa è quando si sviluppa un'applicazione CodeIgniter . CodeIgniter sembra usare le scorciatoie ogni volta che PHP viene usato in un modello / vista, altrimenti con modelli e controller usa sempre i tag lunghi. Non è una regola dura e veloce nel framework, ma per la maggior parte il framework e gran parte della fonte proveniente da altri usi segue questa convenzione.

I miei due centesimi? Se non hai mai intenzione di eseguire il codice da qualche altra parte, usali se vuoi. Preferirei non dover fare una ricerca massiccia e sostituirla quando mi rendo conto che era un'idea stupida.

Answer 15

Ammettiamolo. PHP è brutto da morire senza tag brevi.

Puoi abilitarli in un file .htaccess se non riesci ad accedere al php.ini :

php_flag short_open_tag on

Answer 16

< ;? è disabilitato per impostazione predefinita nelle versioni più recenti. Puoi abilitarlo come descritto Abilitazione breve Tag in PHP .

Answer 17

Le persone IMHO che usano tag brevi spesso dimenticano di sfuggire a qualunque cosa stiano facendo eco. Sarebbe bello avere un motore modello che fuoriesca per impostazione predefinita. Credo che Rob A abbia scritto un trucco rapido per sfuggire ai tag brevi nelle app Zend Frameworks. Se ti piacciono i tag brevi perché rendono PHP più facile da leggere. Quindi Smarty potrebbe essere un'opzione migliore?

{$myString|escape}

per me che sembra migliore di

<?= htmlspecialchars($myString) ?> 

Answer 18

Bisogna chiedersi qual è il punto di usare i tag brevi.

Più veloce da digitare

MDCore ha detto:

  

<? = è molto più conveniente che digitare <? php echo

Sì, lo è. Risparmia di dover digitare 7 caratteri * X volte negli script.

Tuttavia, quando uno script impiega un'ora, o 10 ore o più, per progettare, sviluppare e scrivere, quanto sono importanti i pochi secondi di tempo che non digitano quei 7 caratteri qua e là per la durata dello script?

Rispetto al potenziale per alcuni core, o per tutti, degli script che non funzionano se i tag brevi non sono attivati ??o sono attivi ma un aggiornamento o qualcuno che modifica la configurazione del file / server ini li interrompe, altri potenziali.

Il piccolo vantaggio che ottieni non si avvicina al superamento della gravità dei potenziali problemi, ovvero al fatto che il tuo sito non funziona, o peggio, solo parti di esso non funzionano e quindi un mal di testa da risolvere.

Più facile da leggere

Questo dipende dalla familiarità .
Ho sempre visto e usato <? Php echo . Quindi, sebbene <? = non sia difficile da leggere, non mi è familiare e quindi non è più facile da leggere .

E con la divisione degli sviluppatori front-end / back-end (come con la maggior parte delle aziende) uno sviluppatore front-end che lavora su quei modelli sarebbe più familiare sapendo che <? = è uguale a " tag aperto PHP ed eco " ;?
Direi che la maggior parte sarebbe più a suo agio con quella più logica. Cioè, un tag aperto di PHP chiaro e quindi cosa sta succedendo "quot" echo " - <? php echo .

Valutazione del rischio
Problema = l'intero sito o gli script principali non funzionano;

Il potenziale problema è molto basso + la gravità del risultato è molto alta = alto rischio

Conclusione

Risparmia qualche secondo qua e là senza dover digitare alcuni caratteri, ma rischi molto per questo e probabilmente perdi anche la leggibilità di conseguenza.

I programmatori front-end o back-end familiari con <? = hanno maggiori probabilità di comprendere <? php echo , poiché sono cose standard di PHP - tag aperto <? php standard e molto ben noto " echo " ;.
(Anche i programmatori di front-end dovrebbero conoscere "eco" o semplicemente non lavoreranno su alcun codice servito da un framework).

Mentre il contrario non è altrettanto probabile, è improbabile che qualcuno deduca logicamente che il segno di uguale su un tag short PHP sia "echo".

Answer 19

Per evitare problemi di portabilità, avvia i tag PHP con <? php e nel caso in cui il tuo file PHP sia puramente PHP, senza HTML, non è necessario utilizzare i tag di chiusura.

Answer 20

• I tag brevi sono accettabili da utilizzare nei casi in cui si è certi che il server lo supporterà e che gli sviluppatori lo capiranno.
• Molti server non lo supportano e molti sviluppatori lo capiranno dopo averlo visto una volta.
• Uso tag completi per garantire la portabilità, dal momento che non è poi così male.

Detto questo, un mio amico ha detto questo, a supporto di tag di tipo asp alternativi standardizzati , come <% anziché < ;? , che è un'impostazione in php.ini chiamata asp_tags. Ecco il suo ragionamento:

  

... convenzioni arbitrarie dovrebbero essere   standardizzato . Cioè, ogni volta che lo siamo   di fronte a una serie di possibilità che   hanno tutti lo stesso valore - come cosa   punteggiatura strana la nostra programmazione   il linguaggio dovrebbe usare per delimitare   stesso - dovremmo scegliere uno standard   modo e attenersi ad esso. In questo modo noi   ridurre la curva di apprendimento di tutti   lingue (o qualunque siano le cose   convenzione riguarda).

Mi sembra buono, ma non credo che nessuno di noi possa fare il giro dei carri attorno a questa causa. Nel frattempo, mi atterrei al <? Php completo.

Answer 21

Converti < ;? (senza uno spazio finale) in <? php (con uno spazio finale):

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

Converti < ;? (con uno spazio finale) in <? php (mantenendo lo spazio finale):

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

Answer 22

Ho pensato che valesse la pena menzionarlo a partire da PHP 7:

• Tag ASP PHP brevi <% & # 8230; % > sono spariti
• Schede PHP brevi < ;? & # 8230; ? > sono ancora disponibili se short_open_tag è impostato su true. Questo è il valore predefinito.
• Da PHP 5.4, i tag Stampa corti <? = & # 8230; ? > sono sempre abilitati, indipendentemente dall'impostazione short_open_tag .

Buon viaggio con il primo, poiché interferiva con altre lingue.

Ora non c'è motivo di non usare i tag di stampa brevi, a parte le preferenze personali.

Naturalmente, se stai scrivendo codice per essere compatibile con le versioni legacy di PHP 5, dovrai attenerti alle vecchie regole, ma ricorda che qualsiasi cosa prima di PHP 5.6 non è ora supportata.

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

Answer 23

Se ti interessa XSS , dovresti usare < ;? = htmlspecialchars (& # 8230;)? > il più delle volte, quindi un tag corto non fa una grande differenza.

Anche se accorcia echo htmlspecialchars () a h () , è ancora un problema che devi ricordare di aggiungere quasi ogni volta (e cercando di mantenere tracciare quali dati sono pre-salvati, che sono senza caratteri di escape ma innocui rendono solo gli errori più probabili).

Uso un motore di template che è sicuro per impostazione predefinita e scrive <? php tag per me.

Answer 24

<? php? > sono molto meglio da usare poiché gli sviluppatori di questo linguaggio di programmazione hanno aggiornato in maniera massiccia il loro linguaggio principale. Puoi vedere la differenza tra i tag brevi e quelli lunghi.

I tag brevi saranno evidenziati in rosso chiaro mentre quelli più lunghi sono evidenziati in modo più scuro!

Tuttavia, riecheggiando qualcosa, ad esempio: <? = $ variabile;? > va bene. Ma preferisci i tag più lunghi. <? php echo $ variabile;? >

Answer 25

I tag brevi sono sempre disponibili in php.     Quindi non è necessario fare eco alla prima istruzione nel tuo script

Esempio:

    $a =10;
    <?= $a;//10 
    echo "Hellow";//
    echo "Hellow";

   ?>

All'improvviso devi usare un singolo script php, quindi puoi farlo     usalo.     Esempio:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>

Answer 26

No, e sono essere gradualmente eliminato da PHP 6 , quindi se apprezzi la longevità del codice, semplicemente non usali o i tag <% ...% > .