Podstawy: osadzanie kodu PHP w pliku
Żeby nie zanudzać tym, co już zostało wiele razy napisane, napiszę szybko, że istnieją 4 sposoby osadzania kodu PHP w pliku, z czego 2 najpopularniejsze wyglądają tak:
<?php $tutaj_kod // sposób standardowy ?> <? $tutaj_kod // sposób skrócony ?>
O pozostałych dwóch (tag <script language='php'>… i znany z ASP <% … %>) najlepiej od razu zapomnieć, chociażby z tego powodu, że nikt ich nie używa, a pierwszy z nich dodatkowo jest długi, brzydki i nie da się go mieszać z HTML-em.
Więc który sposób jest lepszy?
Jeśli tworzysz oprogramowanie, które ma być możliwie kompatybilne z wszelkimi serwerami i ich konfiguracjami (np. gdy tworzysz framework lub jakąś bibliotekę) właściwie musisz stosować zapis standardowy. Oszczędzi to zapewne wiele frustracji użytkownikom, bo jest to sposób, który zawsze działa. Jeśli jednak opisywany przypadek Cię nie dotyczy to warto stosować zapis skrócony (my go właśnie stosujemy bezproblemowo od dłuższego czasu). Wymaga on co prawda włączenia dyrektywy short_open_tag = On w pliku php.ini, jednak tworzony kod zyskuje sporo na czytelności. Do trybu PHP wskakujemy wtedy umieszczając tylko 2 znaki zamiast 5, natomiast zapis <?php echo 'Cześć' ?> można skrócić się aż o 7 znaków do <?= 'Cześć' ?>. A skoro można coś zapisać krócej, to czemu tego nie zrobić?
Co warto wiedzieć o wychodzeniu z „trybu PHP”
PHP wymaga kończenia instrukcji średnikiem. Jak jednak widać w poprzednim akapicie, tego średnika nie ma. Jest to dopuszczalne, ponieważ wyjście z „trybu PHP” (?>) samo wstawia brakujący średnik. Warto to wykorzystać i nie zaciemniać kodu niepotrzebnymi znakami, szczególnie w przypadku gdy „wchodzimy” i „wychodzimy” do PHP w tej samej linii.
Inną sprawą jest fakt, że pliki zawierające w całości kod PHP, nie muszą i właściwie nie powinny mieć zakończenia „trybu PHP” (wtedy jednak nie wolno pominąć średnika w ostatniej instrukcji). Chroni nas to przed specyficzną sytuacją, gdy omyłkowo pozostawione puste linie w plikach ładowanych za pomocą funkcji include lub require spowodują rozpoczęcie wysyłania odpowiedzi (PHP od razu wysyła treść, która nie jest buforowana, ani nie jest kodem PHP), czego typowym następstwem jest komunikat:
[…] headers already sent by […]
Podobne wpisy:
- Zapamiętywanie hasła dla PostgreSQL w pliku
- Logowanie do pliku wszystkich zapytań w PostgreSQL
- Adobe AIR podstaw podstawy
Autorzy zdjęć: Robert Bejil Photography
Muszę Cię nauczyć ładne strzałki sadzić ;)
Przy wyborze pomiędzy skróconą wersją wchodzenia w tryb PHP i standardową należy zwrócić uwagę przede wszystkim na to na czym strona będzie postawiona. To znaczy czy serwer będzie nasz, bądź mamy nad ustawieniami PHPa pełną kontrolę, czy nie. Bo kiedy nie mam pewności na jakim serwerze będzie stała pisana przeze mnie strona to używam standardowego zapisu.
I nie wierzę w to, że na koniec można sobie zamienić każde
a ja mam pytanie, czy wiedząc, że w tak małym fragmencie kodu tak dużo będzie kodu PHP, czy nie lepiej raz otworzyć znaczniki PHP i pociągnąć kod kilka lini i dopiero później zamknąć?
Ja bym nie brał pod uwagę tego ile kodu PHP będzie, tylko to jakiego stylu się trzymamy. Najważniejsza jest spójność.
@Noisy: jeśli masz na myśli printowanie HTMLa z PHP, to szczerze mówiąc wolę często otwierać i zamykać znaczniki (szczególnie w skrótowej formie). To oczywiście kwestia gustu, ale tylko jeśli mam naprawdę otwierać co znak PHPa, to przechodzę na jakieś printfy.
Poza tym rzeczywiście – podstawa to spójność. Większość konwencji można obronić, ale muszą być stosowane konsekwentnie.
W przyszłości skrócony format będzie usunięty więc odpowiedź sama ciśnie się na usta.
Korzystając z okazji: lepiej tak niż używać systemu szablonów. Żaden system szablonów i jego parser nie może być szybszy od „czystego” PHP.
Ze wstępnego changelogoa do PHP 5.4:
- <?= is now always available regardless of the short_tags setting