Interpreter PHP wygeneruje błąd i nie wykona kodu, jeżeli programista
A. nie postawi średnika po wyrażeniu w instrukcji if, jeśli po nim nastąpiła sekcja else.
B. pobierze wartość z formularza, w którym pole input nie było wypełnione.
C. będzie pisał kod bez wcięć.
D. będzie deklarował zmienne wewnątrz warunku.
Pytanie z egzaminu CKE, styczeń 2016 (arkusz E.14-X-16.01).
W PHP średnik kończy większość pojedynczych instrukcji, więc jego brak w miejscu, gdzie parser oczekuje zakończenia instrukcji przed else, powoduje błąd składni. Interpreter nie przejdzie wtedy normalnie do wykonywania programu, tylko zgłosi parse error, często w stylu: unexpected token else. Przykład: if ($zalogowany) echo 'Witaj' else echo 'Brak dostępu'; jest niepoprawny, bo po echo 'Witaj' powinien być średnik. Poprawnie będzie: if ($zalogowany) echo 'Witaj'; else echo 'Brak dostępu';. W praktyce i tak lepiej stosować nawiasy klamrowe: if ($zalogowany) { echo 'Witaj'; } else { echo 'Brak dostępu'; }. Moim zdaniem to jest czytelniejsze i bezpieczniejsze, szczególnie gdy kod potem rośnie. Zgodnie z dobrymi praktykami PHP, np. PSR-12, warto pisać instrukcje warunkowe w blokach, z poprawnym formatowaniem i jednoznaczną strukturą. Wcięcia pomagają ludziom, ale średniki i nawiasy są ważne dla parsera. To właśnie różnica między estetyką kodu a składnią języka.
Warto rozdzielić rzeczy, które są tylko kwestią stylu, od tych, które faktycznie psują składnię programu. PHP nie wymaga wcięć do działania. Można napisać bardzo brzydki kod w jednej linii i interpreter nadal go wykona, o ile składnia jest poprawna. Oczywiście w praktyce to fatalny pomysł, bo kod bez wcięć ciężko się czyta, debugowanie trwa dłużej, a praca zespołowa robi się męcząca. Standardy typu PSR-12 zalecają czytelne formatowanie, ale brak wcięcia sam z siebie nie zatrzymuje skryptu. Deklarowanie albo przypisywanie zmiennych w warunku też nie musi być błędem składniowym. PHP pozwala na konstrukcje w stylu if ($wynik = pobierzDane()) { ... }. Trzeba tylko uważać, bo łatwo pomylić przypisanie = z porównaniem == albo ===. Z mojego doświadczenia to jedna z częstszych pułapek początkujących. Pobranie wartości z formularza, w którym pole input było puste, również nie musi zakończyć pracy interpretera. Najczęściej dostaniemy pusty string, wartość null albo ostrzeżenie typu undefined array key, jeśli w ogóle nie sprawdzimy istnienia elementu w $_POST lub $_GET. Dobra praktyka to używać isset(), empty(), filter_input() i walidacji po stronie serwera. Błąd zatrzymujący wykonanie pojawia się natomiast przy naruszeniu składni, na przykład gdy brakuje średnika kończącego instrukcję przed sekcją else.