Czy krótkie tagi PHP są dopuszczalne?

Zbyt Lubię <?=$whatever?>, żeby odpuścić. Nigdy nie miałem z tym problemu. Poczekam, aż ugryzie mnie w tyłek. Ogólnie rzecz biorąc, 85% (moich) klientów ma dostęp do php.ini w rzadkie okazje są wyłączone. Pozostałe 15% korzysta z głównych dostawców hostingu i praktycznie wszyscy z nich mają je włączone. Kocham je.

Począwszy od PHP 5.4, Skrót echo jest oddzielnym problemem od krótkich tagów, ponieważ Skrót echo zawsze będzie włączony. To już fakt:

• SVN Revision by Rasmus Lerdorf
• dyskusja listy dyskusyjnej

Więc sam skrót echo (<?=) jest teraz bezpieczny w użyciu.

Problem z całą tą dyskusją polega na użyciu PHP jako języka szablonów. Nikt nie argumentuje, że znaczniki powinny być używane w plikach źródłowych aplikacji.

Jednak składnia PHP pozwala na używanie go jako potężnego języka szablonów, a szablony powinny być tak proste i czytelne, jak to tylko możliwe. Wielu uznało, że łatwiej jest używać znacznie wolniejszego, dodatkowego silnika szablonów, takiego jak Smarty, ale dla tych purystów wśród nas, którzy wymagają szybkiego renderowania i czystej bazy kodu, PHP jest jedyny sposób na pisanie szablonów.

Jedynym słusznym argumentem przeciwko używaniu krótkich tagów jest to, że nie są one obsługiwane na wszystkich serwerach. Komentarze dotyczące konfliktów z dokumentami XML są niedorzeczne, ponieważ prawdopodobnie nie powinieneś mieszać PHP i XML; a jeśli tak, powinieneś używać PHP do wypisywania ciągów tekstowych. Bezpieczeństwo nigdy nie powinno być problemem, ponieważ jeśli umieszczasz poufne informacje, takie jak poświadczenia dostępu do bazy danych wewnątrz plików szablonów, cóż, masz większe problemy!

Teraz, co do kwestii obsługi serwerów, trzeba być świadomym ich docelowej platformy. Jeśli hosting współdzielony jest prawdopodobnym celem, należy unikać krótkich tagów. Ale dla wielu profesjonalnych programistów (takich jak ja), klient przyznaje (i rzeczywiście, zależy od faktu), że będziemy dyktować wymagania serwera. Często sam jestem odpowiedzialny za konfigurację serwera.

I nigdy nie pracujemy z dostawcą hostingu, który nie daje nam absolutna kontrola nad konfiguracją serwera - w takim przypadku możemy liczyć na znacznie więcej kłopotów niż tylko utratę krótkiej obsługi tagów. To się po prostu nie zdarza.

Więc tak -- Zgadzam się, że stosowanie krótkich metek powinno być starannie zważone. Ale też mocno wierzę, że zawsze powinna być opcja i że deweloper, który jest świadomy swojego środowiska, powinien czuć się swobodnie z nich korzystać.

Krótkie tagi wracają dzięki Zend Framework wciskając " PHP jako język szablonowy " w ich domyślnej konfiguracji MVC . Nie wiem, o czym jest ta debata, większość oprogramowania, które będziesz produkował w swoim życiu, będzie działać na serwerze, który kontrolujesz ty lub Twoja firma. Dopóki będziesz konsekwentny, nie powinno być żadnych problemów.

UPDATE

Po wykonaniu sporej pracy z Magento , który używa długiej formy. W rezultacie przełączyłem się na długą formę:

<?php and <?php echo

Over

<? and <?=

Wydaje się niewielką ilością pracy, aby zapewnić interoperacyjność.

Ponieważ zamieszanie może generować z deklaracjami XML. Wiele osób zgadza się z tobą.

Dodatkowym problemem jest ból, który generuje kodowanie wszystkiego za pomocą krótkich tagów, aby dowiedzieć się na końcu, że ostateczny serwer hostingowy je wyłączył...

Poniżej znajduje się wspaniały schemat przepływu tego samego:

Source: similar question on Software Engineering Stack Exchange

Http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php ma wiele rad, w tym:

Podczas gdy niektórzy ludzie znajdują krótkie znaczniki i Tagi stylu ASP wygodne, są mniej przenośny i generalnie nie polecam.

I

Zauważ, że jeśli osadzasz PHP w XML lub XHTML będziesz musiał użyj znaczników <?php ?>, aby pozostać zgodny ze standardami.

I

Używanie krótkich znaczników powinno być unika się podczas tworzenia aplikacji lub biblioteki, które przeznaczone są dla redystrybucja, czyli wdrożenie w PHP serwery, które nie są pod twoim kontroli, ponieważ krótkie znaczniki mogą nie być obsługiwane na serwerze docelowym. Na portable, redistributable code, be nie używaj krótkich metek.

Na wypadek, gdyby ktoś nadal zwracał na to uwagę... Od wersji PHP 5.4.0 Alpha 1 <?= jest zawsze dostępna:

Http://php.net/releases/NEWS_5_4_0_alpha1.txt

Więc wygląda na to, że krótkie znaczniki są (a) dopuszczalne i (b) tutaj, aby pozostać. Przynajmniej na razie...

• Krótkie Tagi nie są domyślnie włączone w niektórych serwerach (współdzielonych hostach, itp.), więc przenoszenie kodu staje się problemem, jeśli musisz przenieść się do jednego z nich.

• Czytelność może być problemem dla niektórych. Wielu programistów może zauważyć, że <?php przyciąga wzrok jako bardziej oczywisty znacznik początku bloku kodu niż <? podczas skanowania pliku, szczególnie jeśli utkniesz z bazą kodu z HTML i PHP ściśle Międzyzdroje.

Uwaga: począwszy od PHP 5.4 krótki tag, <?=, jest teraz zawsze dostępny.

Przeczytałem tę stronę po poszukiwaniach informacji na ten temat i uważam, że nie wspomniano o jednej ważnej kwestii: lenistwo a konsekwencja. "Prawdziwe" tagi dla PHP to . Dlaczego? Nie obchodzi mnie to. Dlaczego chcesz używać czegoś innego, skoro są one wyraźnie dla PHP? znaczy dla mnie ASP, a

Chociaż posiadanie wielu opcji jest miłe, to wcale nie jest logiczne i może powodować problemy. Wyobraź sobie, że każdy język programowania dopuszcza 4 lub więcej typów tagów: Javascript może być

Wreszcie, nie sądzę, że krótkie znaczniki są tutaj problemem: istnieją tylko dwa logiczne typy bloków kodu PHP: 1) zwykły kod PHP, 2) ECHA szablonów. Dla tych pierwszych mocno wierzę, że tylko powinno być dozwolone tylko, aby wszystko było spójne i przenośne. Dla tego drugiego = $var?> metoda jest brzydka. Dlaczego tak musi być? Dlaczego nie dodać czegoś bardziej logicznego? To nic by nie dało (i tylko w najbardziej odległych możliwościach mogłoby z czymś kolidować), a to mogłoby łatwo zastąpić niewygodne = składnia. A jeśli to problem, może przydałoby się zamiast i nie martw się o niespójności.

W momencie, gdy istnieją 4 opcje dla tagów open I close oraz losowe dodanie specjalnego znacznika "echo", PHP może równie dobrze mieć w php flagę "custom open/close tags".ini lub .htaccess. W ten sposób projektanci mogą wybrać ten, który najbardziej im się podoba. Ale z oczywistych powodów to przesada. Po co więc zezwalać na opcje 4+?

Dobrze jest ich używać podczas pracy z frameworkiem MVC lub CMS, które mają oddzielne pliki widoku.
jest szybki, mniej kodu, nie mylący dla projektantów. Po prostu upewnij się, że konfiguracja serwera pozwala na korzystanie z nich.

Jedną z sytuacji, która jest nieco inna, jest tworzenie aplikacji CodeIgniter . CodeIgniter zdaje się używać shorttagów, gdy PHP jest używane w szablonie/widoku, w przeciwnym razie w modelach i kontrolerach zawsze używa długich tagów. Nie jest to trudna i szybka zasada w frameworku, ale w przeważającej części Framework i wiele źródeł z innych zastosowań jest zgodne z tą konwencją.

Moje dwa centy? Jeśli nigdy nie planujesz uruchomić kodu gdzie indziej, użyj jeśli chcesz. Wolałbym nie musieć masowych poszukiwań i zastępować, gdy zdam sobie sprawę, że to był głupi pomysł.

Spójrzmy prawdzie w oczy. PHP jest brzydkie jak diabli bez krótkich tagów.

Możesz włączyć je w pliku .htaccess, jeśli nie możesz dostać się do php.ini:

php_flag short_open_tag on

<? jest domyślnie wyłączona w nowszych wersjach. Możesz to włączyć w sposób opisany Włączanie krótkich tagów w PHP.

IMHO ludzie, którzy używają krótkich tagów często zapominają uciec od tego, co robią. Byłoby miło mieć silnik szablonów, który domyślnie ucieka. Wierzę, że Rob a napisał szybki hack, aby uniknąć krótkich tagów w aplikacjach Zend Framework. Jeśli lubisz krótkie tagi, ponieważ sprawia, że PHP jest łatwiejsze do odczytania. Czy Smarty może być lepszym rozwiązaniem?

{$myString|escape}

Dla mnie to wygląda lepiej niż

<?= htmlspecialchars($myString) ?> 

Trzeba zapytać, jaki jest sens używania krótkich tagów.

Szybciej wpisać

MDCore powiedział:

<?= jest o wiele wygodniejsze niż pisanie <?php echo

Jednak, gdy skrypt zajmuje godzinę, lub 10 godzin lub więcej, aby zaprojektować, rozwinąć i napisać, jak istotne jest kilka sekund czasu nie wpisując tych 7 znaków tu i tam dla czas trwania scenariusza?

W porównaniu z potencjałem, że niektóre podstawowe lub wszystkie skrypty nie działają, jeśli krótkie znaczniki nie są włączone lub są włączone, ale aktualizacja lub ktoś zmieniający konfigurację pliku INI/serwera zatrzymuje ich działanie, inne możliwości.

Mała korzyść, którą zyskujesz, nie zbliża się do przeważenia wagi potencjalnych problemów, czyli Twoja witryna nie działa, lub co gorsza, tylko jej części nie działają, a tym samym ból głowy do rozwiązania.

Łatwiejszy do odczytania

To zależy od znajomości .
Zawsze widziałem i używałem <?php echo. Więc chociaż {[0] } nie jest trudne do odczytania, nie jest mi znane, a zatem Nie łatwiejsze do odczytania .

A przy podziale front end/back end developer (jak w większości firm) czy front end developer pracujący nad tymi szablonami byłby bardziej znany wiedząc, że <?= jest równe "PHP open tag i echo"?
Powiedziałbym, że większość będzie bardziej wygodny z bardziej logicznym. Oznacza to, że czysty znacznik PHP open, a następnie co się dzieje "echo" - <?php echo.

Ocena ryzyka
Problem = nie działa cała strona lub podstawowe Skrypty;

Potencjał problemu jest bardzo niski + nasilenie wyniku jest bardzo wysoki = wysokie ryzyko

Wniosek

Oszczędzasz kilka sekund tu i ówdzie nie musisz wpisywać kilku znaków, ale wiele ryzykujesz, a także prawdopodobnie w wyniku tego stracisz czytelność.

Przedni lub tylni koderzy znajomi Z <?= są bardziej skłonni do zrozumienia <?php echo, ponieważ są standardowymi rzeczami PHP - standardowym otwartym znacznikiem <?php i bardzo dobrze znanym "echo".
(Nawet programiści powinni znać "echo" lub po prostu nie będą pracować na dowolnym kodzie obsługiwanym przez framework).

Podczas gdy odwrotność nie jest tak prawdopodobna, ktoś nie może logicznie wydedukować, że znak równości na krótkim znaczniku PHP to "echo".

Aby uniknąć problemów z przenośnością, Uruchom znaczniki PHP z <?php i jeśli Twój plik PHP jest czysto PHP, bez HTML, nie musisz używać tagów zamykających.

• krótkie znaczniki są dopuszczalne w przypadkach, gdy jesteś pewien, że serwer będzie je obsługiwał i że twoi Programiści to zrozumieją.
• Wiele serwerów go nie obsługuje, a wielu programistów zrozumie go po obejrzeniu go raz.
• używam pełnych tagów, aby zapewnić przenośność, ponieważ naprawdę nie jest tak źle.

Z tym, że powiedział, Mój przyjaciel powiedział to, w celu wsparcia alternatywnego standaryzowane znaczniki w stylu asp, jak <% zamiast <?, który jest ustawienie w php.ini nazywa asp_tags. Oto jego rozumowanie:

... arbitralne konwencje powinny być standaryzowane . Czyli za każdym razem, gdy jesteśmy w obliczu zestawu możliwości, które są wszystkie o równej wartości - takie jak to, co dziwna interpunkcja nasze programowanie język powinien używać do rozgraniczania siebie - powinniśmy wybrać jeden standard sposób i trzymaj się tego. W ten sposób zmniejsz krzywą uczenia się wszystkich języki (czy cokolwiek to konwencja dotyczy do).

Konwertuj <? (bez spacji końcowej) na <?php (ze spacją końcową):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

Konwertuj <? (ze spacją końcową) na <?php (zachowując przestrzeń końcową):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'

Pomyślałem, że warto wspomnieć, że od PHP 7:

• krótkie tagi PHP <? … ?> zniknęły
• od wersji PHP 5.4, krótkiePrint znaczniki <?=… ?> sązawsze włączone, niezależnie od ustawienia short_open_tag.

Nie ma teraz powodu, aby nie używać krótkich znaczników drukowania, poza osobistymi preferencjami.

Oczywiście, jeśli piszesz kod, aby był kompatybilny ze starszymi wersjami PHP 5, musisz trzymać się starych zasad, ale pamiętaj, że wszystko przed PHP 5.6 jest teraz nieobsługiwane.

Zobacz: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Jeśli zależy ci na XSS to powinieneś używać <?= htmlspecialchars(…) ?> przez większość czasu, więc krótki tag nie robi wielkiej różnicy.

Nawet jeśli skrócisz echo htmlspecialchars() do h(), nadal jest problem, że musisz pamiętać, aby dodawać go prawie za każdym razem(a próba śledzenia, które dane są wcześniej uciekane, co jest nieoznaczone-ale-nieszkodliwe tylko sprawia, że błędy są bardziej prawdopodobne).

Używam silnika szablonów, który jest domyślnie bezpieczny i pisze <?php tagi dla mnie.

<?php ?> są znacznie lepsze w użyciu, ponieważ twórcy tego języka programowania ma masowo zaktualizowane ich rdzeń-język. Możesz zobaczyć różnicę między krótkimi znacznikami i długimi znacznikami.

Krótkie znaczniki będą podświetlone na czerwono, podczas gdy dłuższe będą podświetlone ciemniej!

Jednak, ECHA coś, na przykład: <?=$variable;?> jest w porządku. Ale wolę dłuższe tagi. <?php echo $variable;?>

Nie, a są one wycofywane przez PHP 6 , więc jeśli doceniasz długowieczność kodu, po prostu nie używaj ich ani znaczników <% ... %>.