Chiusura tag (?>) Su file PHP?


17

Alcune persone giurano chiudendo i loro file PHP con ?>, alcuni dicono che è più ottimizzato per lasciarlo fuori.

So che non è essenziale averlo lì, mi sto solo chiedendo quali sono i pro e i contro di fare questo e quali sono le migliori pratiche.



Alcune persone presumono che la frase "più ottimizzato" intendesse significare "funzionerà più velocemente". L'oratore (la cui prima lingua potrebbe non essere l'inglese) potrebbe aver inteso qualcosa di più simile a "più ottimale" o "una pratica migliore".
Scott C Wilson,

Risposte:


27

Non è tanto una questione di prestazioni: l'analisi del trailing ?>è banale e non farà alcuna differenza evidente, a meno che non si includa un milione di file al secondo.

IIRC, php.net consiglia di NON aggiungere il ?>, e le ragioni vanno in questo modo:

  • non è necessario
  • è facile aggiungere accidentalmente spazi vuoti significativi dopo il ?>, che verranno inviati al client, il che a sua volta può portare a oscuri errori di "intestazioni già inviati" (ciò accade quando un file incluso contiene spazi bianchi e si tenta di impostare un'intestazione dopo incluso quel file)

Sulla base delle risposte qui (in particolare per quanto riguarda lo spazio bianco indesiderato vuoto che causa errori "header già inviati"), ho cambiato la mia abitudine di includere religiosamente un?> Alla fine di un file PHP. Ho notato che quando ho creato un nuovo file con PHPStorm il modello ha appena inserito un <? Php senza il tag di chiusura?> E ho pensato che fosse solo un codice sciatto. Adesso lo so meglio.
Tcrosley,

Questa precisa ragione - "intestazioni già inviate" - è stata la ragione per cui è stato rigorosamente vietato dal mio datore di lavoro (un grande portale web). È una cosa quando lo dimentichi alla fine di un file che hai appena scritto. È un altro se modifichi una voce di libreria che è 3 include in profondità, il tuo editor di testo inserisce lo spazio bianco a tua insaputa, e improvvisamente un pezzo di portale gestito da ragazzi a 2 edifici di distanza smette di funzionare. L'albero di include spesso più di 100 file, trovare il bug diventa un esercizio di pazienza. Aspettati una visita di "profonda gratitudine" settimane dopo, quando il bug viene rilevato e ricondotto a te.
SF.

1
PHP che invia spazio bianco dopo il tag di chiusura è un altro esempio di decisioni linguistiche scadenti.
user949300,

12

No, hanno torto.

?>è facoltativo in PHP alla fine di un file. E troverai una buona ragione per questo. Il più importante è che uno spazio vuoto alla fine di un file non ti impedirà di inviare le intestazioni. Questo è un bug difficile da individuare perché puoi trovarlo in qualsiasi file ovunque.

Il solito modo di fare è inserire un tag di chiusura quando PHP viene mischiato con HTML e non inserirlo in file PHP puri. È persino uno standard di codifica dal framework ZEND e molti altri.

Ottimizzato significa che il codice viene eseguito più velocemente. È facile dimostrarli sbagliati. Profila il codice e scopri che ti stanno dicendo delle cazzate.


4

Penso che sia consigliato ai neofiti di evitare di aggiungerlo in modo che non causino l'invio accidentale di nuovi caratteri di newline. Dal momento che non è essenziale averlo come hai menzionato, penso che il ragionamento generale sia che è meglio lasciarlo fuori per evitare errori.

Non credo ci sia alcuna "ottimizzazione" coinvolta.

Vorrei indicarti qui: /programming/4410704/php-closing-tag e qui: /programming/3219383/why-do-some-scripts-omit-the -chiusura-php-tag


1
principianti o no ... semplicemente non c'è motivo (tranne che per i casi di DOC) di averli
Mchl

@Mchl Vorrei sottolineare che le ragioni per smettere sono abbastanza banali e alla fine si riduce solo alla preferenza del programmatore e non è davvero un problema di disturbo ossessivo compulsivo ...
Kenneth

1
Mi arrabbio ogni volta che vedo ?>nei file contenenti puro PHP.
Caffeinated Aviator,

@Kenneth: se sono banali, non riesco a vederli. La parte OCD era intesa come uno scherzo.
McL
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.