I tag brevi PHP sono accettabili da usare?

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?

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.

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.

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.

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.

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

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

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

Fonte: domanda simile su Software Engineering Stack Exchange

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.

Nel caso in cui qualcuno <?=stia ancora prestando 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 ...

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

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

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?

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

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.

<?è disabilitato per impostazione predefinita nelle versioni più recenti. Puoi abilitarlo come descritto Abilitare i Short Tag in PHP .

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) ?> 

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

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

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.

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

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

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.

<?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;?>

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'

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>

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 .

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

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