Tag penutup (?>) Pada file PHP?


17

Beberapa orang bersumpah dengan menutup file PHP mereka ?>, beberapa mengatakan itu lebih dioptimalkan untuk membiarkannya.

Saya tahu bahwa tidak penting untuk memilikinya di sana, saya hanya ingin tahu apa pro dan kontra dari melakukan ini, dan apa praktik terbaiknya.



Beberapa orang menganggap ungkapan "lebih dioptimalkan" dimaksudkan untuk berarti "akan berjalan lebih cepat." Pembicara (yang bahasa pertamanya mungkin bukan bahasa Inggris) mungkin bermaksud sesuatu yang lebih seperti "lebih optimal" atau "praktik yang lebih baik."
Scott C Wilson

Jawaban:


27

Ini tidak terlalu masalah kinerja - parsing trailing ?>itu sepele dan tidak akan membuat perbedaan nyata sama sekali, kecuali jika Anda memasukkan sejuta file per detik.

IIRC, php.net merekomendasikan JANGAN menambahkan ?>, dan alasannya kira-kira seperti ini:

  • itu tidak perlu
  • mudah untuk secara tidak sengaja menambahkan spasi putih yang signifikan setelah ?>, yang akan menjadi output ke klien, yang pada gilirannya dapat menyebabkan kesalahan 'header sudah terkirim' tidak jelas (ini terjadi ketika file yang disertakan berisi spasi putih, dan Anda mencoba mengatur header setelah termasuk file itu)

Berdasarkan jawaban di sini (terutama mengenai ruang kosong yang tidak diinginkan yang menyebabkan kesalahan "header sudah terkirim"), saya telah mengubah kebiasaan saya secara religius termasuk a?> Di akhir file PHP. Saya perhatikan ketika saya membuat file baru dengan PHPStorm template baru saja memasukkan tag penutup <? Php tanpa?>, Dan berpikir itu hanya coding yang ceroboh. Sekarang saya tahu lebih baik.
tcrosley

Alasan yang tepat ini - "tajuk sudah dikirim" - adalah alasan ini telah dilarang keras oleh majikan saya (portal web besar). Ini adalah satu hal ketika Anda lupa di akhir file yang baru saja Anda tulis. Lain lagi jika Anda mengedit entri perpustakaan yang dalamnya 3, editor teks Anda menyisipkan spasi putih tanpa Anda sadari, dan tiba-tiba sepotong portal yang dijalankan oleh orang-orang 2 bangunan jauhnya berhenti berfungsi. Pohon menyertakan sering 100+ file, menemukan bug menjadi latihan dalam kesabaran. Harapkan "terima kasih yang mendalam" mengunjungi minggu kemudian karena bug ditemukan dan ditelusuri kembali ke Anda.
SF.

1
PHP mengirimkan ruang kosong setelah tag penutup adalah contoh lain dari keputusan bahasa yang buruk.
user949300

12

Tidak, mereka salah.

?>opsional di PHP di akhir file. Dan Anda akan menemukan alasan bagus untuk ini. Yang paling penting adalah ruang kosong di akhir file tidak akan mencegah Anda mengirim header. Ini adalah bug yang sulit dikenali karena Anda dapat menemukannya di file mana saja.

Cara yang biasa dilakukan adalah meletakkan tag penutup ketika PHP dicampur dengan HTML dan tidak meletakkannya untuk file PHP murni. Bahkan standar pengkodean dari kerangka ZEND dan banyak lainnya.

Dioptimalkan berarti kode berjalan lebih cepat. Ini mudah untuk membuktikan bahwa mereka salah. Profil kode dan cari tahu bahwa mereka memberitahu Anda omong kosong.


4

Saya pikir disarankan bagi pemula untuk menghindari menambahkannya sehingga mereka tidak menyebabkan chars baris baru tambahan dikirim secara tidak sengaja. Karena tidak penting untuk memilikinya seperti yang telah Anda sebutkan, saya pikir alasan umumnya adalah lebih baik tinggalkan saja untuk menghindari kesalahan.

Saya tidak berpikir ada "optimasi" yang terlibat dengannya.

Saya akan mengarahkan Anda ke sini: /programming/4410704/php-closing-tag dan di sini: /programming/3219383/why-do-some-scripts-omit-the -tutup-php-tag


1
pemula atau tidak ... tidak ada alasan (kecuali untuk kasus OCD) untuk memilikinya
Mchl

@ Mcl saya akan menunjukkan bahwa alasan untuk meninggalkan cukup sepele dan pada akhirnya hanya karena preferensi programmer dan itu bukan masalah OCD ...
Kenneth

1
Saya merasa ngeri setiap kali saya melihat ?>file yang berisi PHP murni.
Penerbang Berkafein

@ Kenenneth: Jika itu sepele - saya tidak bisa melihatnya. Bagian OCD dimaksudkan sebagai lelucon.
Mchl
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.