I tag brevi PHP sono accettabili da usare?


522

Ecco le informazioni secondo la documentazione ufficiale :

Esistono quattro diverse coppie di tag di apertura e chiusura che possono essere utilizzate 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 possono essere attivati ​​e disattivati ​​dal file di configurazione php.ini. Pertanto, sebbene alcune persone trovino convenienti tag brevi e tag stile ASP, sono meno portatili e generalmente sconsigliati .

Nella mia esperienza maggior parte dei server non hanno tag brevi abilitati. Digitando

<?=

è molto più conveniente della digitazione

<?php echo 

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


61
Per rispondere alla whyparte, vorrei citare la guida alla certificazione Zend PHP 5: "I tag brevi erano, per un certo periodo, lo standard nel mondo PHP; tuttavia, hanno il principale svantaggio di essere in conflitto con le intestazioni XML e, quindi, hanno un po ' caduto a terra ".
Fluffy

7
Qual è il caso d'uso in cui si presenta questo problema, significa che è una seccatura per gli sviluppatori generare XML usando PHP?
Jon z,

9
Supponiamo che tu abbia documenti XML che desideri siano pubblici, ma vuoi che i documenti siano php analizzabili per qualsiasi motivo, in modo da renderli .xml analizzabili dal tuo browser. Si utilizzano tag brevi in ​​modo che siano attivati ​​e all'improvviso il documento XML viene analizzato tramite le intestazioni XML, interrompendo le cose. Mi ha fatto impazzire cercando di capirlo molto tempo fa. Da quando i codici funzione sono stati disabilitati su qualsiasi server in cui corro e qualsiasi squadra con cui ho lavorato ha dovuto ricorrere a codici non brevi
impostare il

43
Da PHP 5.4.0 la direttiva short_open_tag non include il tag echo breve <?= $example;?> ! Questo è molto importante poiché l'uso di tutti gli altri tag brevi è considerato inutile. Ad ogni modo, l'uso del tag eco breve è incoraggiato da ora in poi. Fornisce una base di codice più fluida e ordinata - esp. nei file di visualizzazione. Quindi per PHP> = 5.4.0 <?= ?> può essere usato senza impostazione short_open_tag . Non utilizzare gli altri tag brevi nel codice. Gli dei-codice si arrabbiano molto quando lo fai ...
Borislav Sabev

6
Aggiungerò questo come un breve commento, perché ci sono già troppe risposte lunghe: <?non viene utilizzato solo in XML per la <?xml version="1.0" ?>dichiarazione di apertura ; è la sintassi generale per "istruzioni di elaborazione", essendo il secondo esempio più comune <?xml-stylesheet ... ?>. <?phppuò effettivamente essere considerata un'istruzione di elaborazione valida, come può <?=(come consentito in 5.4+), ma affermare che anche tutto <?ciò crea conflitti inutili tra le sintassi.
IMSoP

Risposte:


374

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 lo fanno shorttags sostegno, ma "lotti" non è tutti. Se vuoi condividere i tuoi script, è meglio usare la sintassi completa.

Sono d'accordo <? e <?=sono più facili per i programmatori rispetto a <?phpe, <?php echoma è possibile fare una ricerca e sostituzione in blocco purché utilizzi lo stesso modulo ogni volta (e non gettare negli spazi (ad esempio: <? phpo<? = )

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, partire da PHP 5.4, 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 utilizzarle<?php echo ... ?>.

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


91
Quindi, la spiegazione è: sono cattivi perché non sono supportati? Ma perché non sono supportati? Perché non fanno parte delle specifiche? Ok, ma perché non fanno parte delle specifiche? Sono un po 'deluso da questa risposta.
Josef Sábl,

61
Non sono qui per discutere delle "grandi domande" come perché siamo qui, come è iniziato tutto, ecc. Il supporto shorttag non è garantito sui server condivisi e verrà rimosso completamente nella prossima versione principale. Questo è tutto quello che avete bisogno di sapere.
Oli,

39
PHP obbligatorio è un motore modello. : P
Errore di sintassi

49
I tag brevi non vengono eliminati gradualmente. Solo tag brevi in ​​stile ASP.
Brian Lacy,

46
Nel futuro (molto vicino) di PHP 5.4, l'uso di <? = Sarà separato dal fatto che short_open_tags sia abilitato o disabilitato. <? = non viene gradualmente eliminato, al contrario è ora considerato un pezzo fondamentale del linguaggio.
Griever,

176

Sono troppo affezionato <?=$whatever?>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 nelle rare occasioni in cui viene spento. L'altro 15% utilizza provider di hosting tradizionali e praticamente tutti li hanno abilitati. Li adoro.


41
@B Seven Se provi a evitare ogni problema teorico che potrebbe sorgere, il tuo codice sarà quasi sicuramente inefficiente e difettoso. Fino a quando il gruppo PHP non accetta di eliminare gradualmente i tag brevi [non i tag ASP], la preoccupazione di essere morso è di gran lunga inferiore e la soluzione potenziale molto più semplice rispetto ad altre cose che è possibile dedicare al "fissaggio".
SamGoody,

18
se ti morde, passa a un hosting migliore
Lie Ryan

4
Non sono davvero d'accordo con non usare qualcosa perché potrebbe non essere supportato. Non dovremmo usare nessuna delle altre funzionalità che potrebbero non essere supportate su un server? MYSQL vs MYSQLI? Perderai tempo a poco a poco, ripetutamente scrivendo tag lunghi solo per evitare una piccola possibilità di passare un po 'di tempo per passare a un host migliore.
Decano o

2
@BSeven, vuoi dire che non usi estensioni PHP tranne quelle predefinite?
Pacerier,

143

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:

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


19
Direi che questo è l'unico "short tag" necessario. <?phppuò essere utilizzato all'inizio di tutti i file di classe e quindi è necessario <?=per le visualizzazioni. win-win.
Xeoncross,

6
So the echo shortcut itself (<?=) is safe to use... purché tu ti senta a tuo agio con PHP 5.4. Le app PHP ampiamente distribuite (come wordpress) non hanno il lusso di richiedere 5.4, e hanno persino continuato a offrire supporto PHP 4 fino al 2011, ben 7 anni dopo il rilascio di PHP 5. Se ti trovi in ​​un posto come Facebook, dove tutte le installazioni del tuo software sono gestite direttamente dalla società stessa, richiedere il supporto per 5.4 è molto più facile che se stai lavorando a un progetto come wordpress.
Frank Farmer,

@dukeofgaming, Wow buona cattura, non sapeva che le loro revisioni SVN sono accessibili sul web.
Pacerier,

82

Il problema di tutta questa discussione risiede nell'uso di PHP come linguaggio esemplare. Nessuno sostiene che i tag debbano essere utilizzati nei file di origine 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, allora hai problemi più grandi!

Ora, per quanto riguarda il problema del supporto del server, bisogna ammettere che è necessario 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 un numero maggiore di problemi rispetto alla perdita del supporto di 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.


6
Se, per qualche motivo, avessi impostato apache per passare i file .xml a mod_php, la cosa <? Xml sarebbe un mal di testa con tag brevi attivi. Ma questa è ovviamente una configurazione bizzarra.
Frank Farmer,

3
Un template linguaggio che non può essere integrato senza soluzioni alternative in alcuni tipi di documenti di output è un grande sicuro. L'unico motivo per cui non dovrei avere un modello XML con codice PHP e tag brevi è perché non funziona, non perché non ha senso.
Vinko Vrsalovic,

8
Non è un "grande fallimento" sfruttare i vantaggi di PHP come linguaggio di template veloce e conveniente. Come ho detto prima, si tratta di valutare i vantaggi e gli svantaggi e di scrivere il codice in modo da soddisfare l'approccio scelto. Non respingere categoricamente un approccio valido solo perché non funziona in uno scenario particolare (che può essere facilmente risolto).
Brian Lacy,

5
Non sto respingendo categoricamente alcun approccio valido (vedi la mia risposta alla domanda.) Tu sei quello che rifiuta categoricamente PHP in XML, cito: "non dovresti comunque mescolare PHP e XML". Inoltre, il grande fallimento a cui mi riferivo era la decisione di utilizzare <?come tag breve, perché porta a brutte soluzioni alternative su XML. Detto questo, concordo sul fatto che si tratta di valutare vantaggi e svantaggi e che se sai cosa stai facendo, puoi sicuramente farlo. Ma questa non è <?una buona scelta.
Vinko Vrsalovic,

3
Sono un po 'in ritardo alla festa, ma mi piace molto questa risposta e rispecchia la mia esperienza con la situazione. Anche se non siamo d'accordo sul problema nel nostro ufficio, posso dire che con un lavoro quasi quotidiano in php per molti anni, non ho mai incontrato questo problema. Quando PHP viene utilizzato per generare XML, nella mia esperienza è sempre stato nel contesto di contenuti altamente dinamici, che non sono mai stati direttamente modellati tramite PHP, quindi il problema non si pone mai.
redreinard

33

I tag brevi stanno tornando grazie a Zend Framework che spinge 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.

AGGIORNARE

Dopo aver fatto un bel po 'di lavoro con Magento , che usa la forma lunga. Di conseguenza, sono passato alla forma lunga di:

<?php and <?php echo

al di sopra di

<? and <?=

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


8
Faccio il freelance e tutto il mio codice passa all'hosting condiviso, quindi nessun controllo! :)
MDCore,

12
Se hai abbastanza clienti che passano alla tua coloc, l'hosting condiviso è insicuro e instabile.
Jake McGraw,

2
I tag corti che Zend stava riportando apparentemente non hanno colto perché Zend sta usando la versione lunga: framework.zend.com/manual/en/zend.view.scripts.html
Gerry

3
@Gerry Ho letto anche questo di recente, vedi l'ultimo commento su questa discussione: Aggiorna .htaccess per abilitare i tag aperti brevi
MrWhite

2
Dovresti davvero correggere la grammatica nella prima frase dopo AGGIORNAMENTO, il che non ha senso nella sua forma attuale.
redreinard

22

Perché la confusione che può generare con le dichiarazioni XML. Molte persone sono d'accordo con te, però.

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 ​​...


La dichiarazione XML non causerà comunque confusione se short_tags è attivo?
MDCore,

Quindi, invece di emettere direttamente la dichiarazione XML, devi farla eco a PHP. Non è davvero un buon rifiuto.
moo,

Non è un rifiuto di nulla. È l'unica vera ragione che a sua volta è la causa dell'altra ragione "hoster lo spegne", ovviamente puoi usarlo se sai cosa stai facendo, come sempre.
Vinko Vrsalovic,

1
@macek: ne sono consapevole. È stato solo il primo esempio a cui ho pensato. Un altro, cosa succede se si incorpora PHP in un file XML? Non puoi farlo direttamente. E non dirmi anche la soluzione a quel problema, ne sono consapevole. Il punto è che ci sono molti modi in cui PHP può analizzare un file XML. Probabilmente puoi eliminarli tutti con soluzioni alternative ( <?='<?xml') o dicendo "non dovresti farlo", ma ciò non fa sparire il fatto che ciò possa accadere.
Vinko Vrsalovic,

1
in che modo i tag corti sono un problema se non funzionano? è molto facile fare un grosso e sostituirlo <?=con <? echo . molti editor di testo sono in grado di gestirlo facilmente su migliaia di file contemporaneamente.
Yamiko,

20

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

albero decisionale dell'uso di <? =

Fonte: domanda simile su Software Engineering Stack Exchange


2
Questo sta descrivendo se usare il tag echo breve, non lo stesso dei <?tag brevi menzionati nella domanda (sebbene abbia usato la stessa impostazione di configurazione pre-5.4)
Alok,

In realtà questa dovrebbe essere una risposta che tutti possono capire, anche se le circostanze non sono davvero spiegate perché non si desidera utilizzare tag brevi in ​​molti casi (ad esempio, non è possibile modificare il file php.ini su un sistema di hosting condiviso)
Björn K

14

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

mentre alcune persone trovano convenienti tag brevi e tag in stile ASP, sono meno portatili e generalmente sconsigliati.

e

nota che se stai incorporando PHP in XML o XHTML dovrai usare i <?php ?>tag per rimanere conforme agli standard.

e

L'uso di tag brevi dovrebbe essere evitato quando si sviluppano applicazioni o librerie destinate alla ridistribuzione o alla distribuzione su server PHP che non sono sotto il vostro controllo, poiché i tag brevi potrebbero non essere supportati sul server di destinazione. Per il codice portatile e ridistribuibile, assicurarsi di non utilizzare tag brevi.



12
  • I tag brevi non sono attivati ​​per impostazione predefinita in alcuni server Web (host condivisi, ecc.), Quindi la portabilità del codice diventa un problema se è necessario passare a uno di questi.

  • La leggibilità può essere un problema per alcuni. Molti sviluppatori potrebbero scoprire che <?phpattira l'attenzione come un indicatore più evidente dell'inizio di un blocco di codice rispetto a <?quando si esegue la scansione di un file, in particolare se si è bloccati con una base di codice con HTML e PHP strettamente intrecciati.


2
I tag brevi sono abilitati nel 95% dei server web.
Paolo Bergantino,

19
Non compro l'argomento "leggibilità". Se stai usando PHP come linguaggio di template, <?= $var ?>è molto più leggibile di<?php echo $var ?>
Frank Farmer,

2
@Paulo potrebbe essere cambiato dal '08 ma le istanze EC2 Ubuntu e Fedora con yum install e le versioni apt-get di PHP hanno il short-tagging disabilitato di default
Doug Molineux,

2
usa tag completi e avrai il 100% :)
Elvis Ciotti,

1
@FrankFarmer, penso che stia confrontando quello senza eco. <?vs <?php.
Pacerier,

11

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


5

Ho letto questa pagina dopo aver cercato informazioni sull'argomento e ritengo che non sia stato menzionato un grosso problema: la pigrizia contro la coerenza. I tag "reali" per PHP sono <? Php e?>. Perché? Non mi interessa davvero. Perché vorresti usare qualcos'altro quando questi sono chiaramente per PHP? <% e%> significano 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'altro canto, sono d'accordo 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 impiegherebbe molto tempo a sprecare tanto tempo digitando i tre caratteri extra 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 penso 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?> Dovrebbero essere autorizzati a mantenere tutto coerente e portatile. Per quest'ultimo, il metodo <? = $ Var?> È 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?> Invece e non preoccuparsi di incoerenze.

Nel punto in cui ci sono 4 opzioni per i tag di apertura e chiusura e l'aggiunta casuale di uno speciale tag "echo", PHP può anche avere un flag "tag di apertura / chiusura personalizzati" 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?


4

È 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.


4

Una situazione leggermente diversa è quando si sviluppa un CodeIgniter un'applicazione . 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 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.



3

Le persone IMHO che usano tag brevi spesso dimenticano di sfuggire a qualsiasi 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 sembra meglio di

<?= htmlspecialchars($myString) ?> 

10
Per la maggior parte dei programmatori PHP, la seconda opzione ha più senso della prima, semplicemente perché è un'effettiva funzione PHP che conosciamo, mentre la prima opzione è il codice pseudo-modello che dobbiamo imparare su PHP. PHP è già un linguaggio di template, aggiungendo un altro linguaggio di template sopra come Smarty è IMO ridondante.
Bug Magnet,

3
Twig è un motore modello con escape HTML abilitato di default twig.sensiolabs.org
mateusza,

3

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

Più veloce da digitare

MDCore ha detto:

<?= è molto più conveniente della digitazione <?php echo

Sì. 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 blocca, 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à .
L'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 ed eco PHP"?
Direi che la maggior parte sarebbe più a suo agio con quella più logica. Cioè, un chiaro tag aperto di PHP e poi cosa sta succedendo "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 = rischio elevato

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.

Anteriore o posteriore programmatori hanno familiarità con <?=hanno più probabilità di capire <?php echo, in quanto sono cose standard di PHP - standard di <?phptag di apertura e molto conosciuto "echo".
(Anche i programmatori front-end dovrebbero conoscere "echo" 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 breve PHP sia "eco".


Non ha nulla a che fare con la digitazione. È più corto e quindi ha il potenziale per essere più facile da leggere . Una persona abituata a leggere <?=leggerà <?=più facilmente di una persona abituata a <?php echoleggere <?php echo.
Pacerier

@Pacerier Shorter non è semplicemente = più facile da leggere. Siamo tutti diversi. Quello che vuoi dire è che è più facile da leggere per te . Come ho inserito la mia risposta, come sono abituato<?php vedere che molte volte nel codice mi è più familiare di <?=- la familiarità rende le cose più facili - anche se non necessariamente migliori.
James,

No, non sto confrontando te e me, sto dicendo che una persona abituata a leggere <?=leggerà <?=meglio di una persona abituata a <?php echoleggere <?php echo. Ciò significa che se abbiamo due copie identiche della persona X e le modifichiamo solo nell'aspetto in cui una è abituata alla lettura <?=e l'altra che è abituata alla lettura <?php echo, la prima copia può raggiungere il valore di leggibilità xdurante la lettura usando la sintassi desiderata, mentre la seconda copia può raggiungere il valore di leggibilità di yquando legge la sua sintassi desiderata, dove x >= y.
Pacerier,

No, ti manca il punto. Mi riferisco al potenziale del sistema, che non ha nulla a che fare con una persona in particolare. Puoi dire che le persone abituate a digitare con la tastiera qwerty digiteranno più velocemente con qwerty, mentre le persone abituate a digitare con dvorak digiteranno più velocemente con dvorak, ma il fatto non cambia che i due sistemi hanno un potenziale diverso.
Pacerier,

3

Affrontiamolo. PHP è brutto da morire senza tag brevi.

Puoi abilitarli in un .htaccessfile se non riesci ad accedere a php.ini:

php_flag short_open_tag on

3
Falso. A volte, il server è impostato per negare qualsiasi tipo di override, signore.
Alfabravo

17
È vero, ma se il tuo host non ti consente di eseguire l'override con htaccess, hai davvero bisogno di un nuovo host! :)
Brian Lacy,

1
non funziona sull'interfaccia della riga di comando e php_flag non è sempre supportato
Elvis Ciotti,

3

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


2
  • 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 stile asp standardizzati alternativi , come <%piuttosto che <?, che è un'impostazione in php.ini chiamata asp_tags. Ecco il suo ragionamento:

... le convenzioni arbitrarie dovrebbero essere standardizzate . Cioè, ogni volta che ci troviamo di fronte a una serie di possibilità che hanno tutti lo stesso valore - come quale strana punteggiatura il nostro linguaggio di programmazione dovrebbe usare per delimitare se stesso - dovremmo scegliere un modo standard e attenerci ad esso. In questo modo riduciamo la curva di apprendimento di tutte le lingue (o qualunque cosa le convenzioni riguardino).

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 massimo <?php.


2

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

  • I tag brevi PHP ASP <% … %>sono spariti
  • Le schede brevi PHP <? … ?>sono ancora disponibili seshort_open_tag è impostata su true. Questo è il valore predefinito.
  • A partire da PHP 5.4, i tag Short Print<?=… ?> sono sempre abilitati, indipendentemente short_open_tagdall'impostazione.

Buon passaggio alla prima, poiché interferiva con altre lingue.

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

Naturalmente, se stai scrivendo un 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


1
A meno che non mi sbagli, il tuo primo punto è errato. Il documento dice che i tag ASP, non i tag PHP brevi, sono spariti a partire da PHP 7.0.0.
riformato il

@reformed Hai assolutamente ragione. Modificherò la mia risposta. Grazie
Manngo,

1

Se ti interessa XSS , dovresti usare la <?= htmlspecialchars(…) ?>maggior parte del tempo, quindi un tag corto non fa una grande differenza.

Anche se si accorcia echo htmlspecialchars()a h(), è ancora un problema che si deve ricordare di aggiungere che quasi ogni volta (e cercando di tenere traccia dei dati, che è pre-sfuggito, che è senza caratteri di escape-ma-innocuo fa solo gli errori più probabile).

Uso un motore di template sicuro per impostazione predefinita e scrive <?phptag per me.


7
Se ti trovi a digitare "<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 volte al giorno, potresti voler creare una funzione di collegamento denominata" h "come Rails ha .." < ? = h ($ text)?> "è molto più leggibile durante la scansione di un modello.
Alexander Malfait,

1
È davvero meglio, ma con un motore di template potrebbe essere semplicemente $ {text} o simile (e non devi ricordarti di aggiungere h ())
Kornel,

7
PHP stesso è un motore di template. Quando smetti di usare i tag brevi, inizia a essere un cattivo motore di template perché diventa troppo prolisso.
Josef Sábl,

1
@Alexander Malfait è un buon consiglio. Ma <? = Non è necessario. Puoi semplicemente fare in modo che la funzione faccia eco alla stringa invece di return, quindi scriverai <? Php h ('hello')?> Non lo facciamo già quando dei18n? <? php _e ('')?> non è poi così male.
VladFr

1

<?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 verranno evidenziati in rosso chiaro mentre quelli più lunghi vengono evidenziati in modo più scuro!

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


1

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'

1

I tag brevi sono sempre disponibili in php. Quindi non hai bisogno di fare eco alla prima affermazione nella tua sceneggiatura

esempio:

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

   ?>

All'improvviso devi usare un solo script php per poterlo usare. esempio:

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

1

A partire dal 2019 non sono d'accordo con alcune risposte qui. Consiglio di usare tag lunghi

<?php /* code goes here */ ?>

o tag di eco brevi

<?= /* code goes here */ ?>

Motivo: sono raccomandati dallo standard di codifica di base PSR-1

Altri tag brevi come <? /* code goes here */ ?>non sono raccomandati.

Le specifiche dicono:

Il codice PHP DEVE utilizzare i tag lunghi o i tag a eco breve; NON DEVE utilizzare le altre varianti di tag .


1

3 tag sono disponibili in php:

  1. tag di lunga durata che <?php ?>non è necessario dirigerne nessuno configurato
  2. short_open_tag <? ?> disponibile se l'opzione short_open_tag in php.ini è attiva
  3. accorcia tag <?= dal php 5.4.0 è sempre disponibile

da php 7.0.0 asp e tag tag vengono rimossi


Questo non risponde alla domanda.
RalfFriedl,

-5

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


4
Ho visto altri post sul blog che dicono che non saranno deprecati, ma solo i tag brevi in ​​stile ASP.
MDCore,

22
Sembra che questa risposta sia errata, secondo questo link dall'incontro degli sviluppatori PHP: php.net/~derick/…
Charles

7
PERCHÉ sono così cattivi, perché? Tutti sono così sicuri di sé che sono baaaaaad ma nessuno dice perché.
Josef Sábl,

6
FALSO. Stanno eliminando i tag <%%>, come invece dovrebbero. Non servono altro che a confondere. Il <? ?> i tag non saranno interessati; ma ovviamente sono ancora configurabili in base al server e dovresti sempre essere consapevole dei requisiti della tua piattaforma di destinazione.
Brian Lacy,

6
Queste informazioni sembrano essere errate e fuorvianti e dovrebbero essere corrette dall'autore.
tex
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.