Czy dopuszczalne są krótkie tagi PHP?

522

Oto informacje zgodnie z oficjalną dokumentacją :

Istnieją cztery różne pary otwierających i zamykających znaczników, których można używać w PHP. Dwa z nich, <?php ?> i <script language="php"> </script>są zawsze dostępne. Pozostałe dwa są krótkimi znacznikami i znacznikami stylu ASP i można je włączać i wyłączać z pliku konfiguracyjnego php.ini. W związku z tym, chociaż niektórzy uważają, że krótkie tagi i tagi stylu ASP są wygodne, są one mniej przenośne i generalnie nie są zalecane .

Z mojego doświadczenia wynika , że większość serwerów ma włączone krótkie tagi. Pisanie na maszynie

<?=

jest o wiele wygodniejszy niż pisanie

<?php echo 

Wygoda programistów jest ważnym czynnikiem, więc dlaczego nie są zalecane?

MDCore
źródło
61
Aby odpowiedzieć na tę whyczęść, cytuję przewodnik certyfikacji Zend PHP 5: „Krótkie tagi były przez pewien czas standardem w świecie PHP; mają jednak poważną wadę polegającą na konflikcie z nagłówkami XML i dlatego mają nieco padł na margines ”.
Puszysty
7
Jaki jest przypadek użycia tego problemu, czy oznacza to, że deweloperzy generują XML przy użyciu PHP?
Jon z
9
Załóżmy, że masz dokumenty XML, które chcesz upublicznić, ale chcesz, aby dokumenty były analizowalne przez php z dowolnego powodu, dzięki czemu plik .xml jest przetwarzalny przez przeglądarkę. Używasz krótkich znaczników, aby były włączone, i nagle dokument XML jest analizowany przez nagłówki XML, co psuje rzeczy. Doprowadziły mnie do szału, próbując to rozgryźć dawno temu. Odkąd krótkie kody zostały wyłączone na każdym serwerze, który uruchamiam, a każdy zespół, z którym pracowałem, musiał uciekać się do kodu
nieskróconego
43
Od PHP 5.4.0 dyrektywa short_open_tag nie zawiera krótkiego znacznika echa <?= $example;?> ! Jest to bardzo ważne, ponieważ użycie wszystkich innych krótkich tagów jest uważane za daremne. W każdym razie odtąd zachęca się do używania krótkiego znacznika echa. Zapewnia płynniejszą i bardziej uporządkowaną bazę kodu - szczególnie. w widoku plików. Tak więc dla PHP> = 5.4.0 <?= ?> można używać bez ustawiania short_open_tag . Nie używaj innych krótkich tagów w kodzie. Kod-Bogowie bardzo się denerwują, kiedy to robisz ...
Borislav Sabev,
6
Dodam to jako szybki komentarz, ponieważ jest już o wiele za dużo długich odpowiedzi: <?nie jest używany tylko w XML do <?xml version="1.0" ?>deklaracji otwierającej ; jest to ogólna składnia „instrukcji przetwarzania”, przy czym drugim najczęściej spotykanym przykładem jest <?xml-stylesheet ... ?>. <?phpmoże być faktycznie uważany za prawidłową instrukcję przetwarzania, tak jak może <?=(jak dozwolone w 5.4+), ale twierdzenie, że całość <?również powoduje niepotrzebny konflikt między składniami.
IMSoP,

Odpowiedzi:

374

Nie są zalecane, ponieważ jest to PITA, jeśli kiedykolwiek będziesz musiał przenieść swój kod na serwer, na którym nie jest obsługiwany (i nie możesz go włączyć). Jak mówisz, wiele wspólnych gospodarzy zrobić shorttags wsparcia, ale „wiele” to nie wszystkie z nich. Jeśli chcesz udostępnić swoje skrypty, najlepiej użyć pełnej składni.

Zgadzam się, że <?i <?=są łatwiejsze niż na programistów <?phpi <?php echoale jest to możliwe do zrobienia większość znajdź i zastąp tak długo, jak korzystać z tego samego formularza za każdym razem (i nie rzucić w przestrzeniach (np: <? phplub <? =)

W ogóle nie kupuję czytelności za przyczynę. Większość poważnych programistów ma możliwość podświetlania składni.

Jak wspomina ThiefMaster w komentarzach, od PHP 5.4 <?= ... ?>tagi są obsługiwane wszędzie, niezależnie od ustawień skrótów . To powinno oznaczać, że można je bezpiecznie używać w przenośnym kodzie, ale to oznacza, że ​​istnieje zależność od PHP 5.4+. Jeśli chcesz obsługiwać wersję starszą niż 5.4 i nie możesz zagwarantować skrótów, nadal musisz użyć <?php echo ... ?>.

Musisz także wiedzieć, że znaczniki ASP <%,%>, <% = i znacznik skryptu są usuwane z PHP 7 . Jeśli więc chcesz obsługiwać długoterminowy przenośny kod i chcesz przejść do najnowocześniejszych narzędzi, rozważ zmianę tej części kodu.

Oli
źródło
91
Zatem wyjaśnienie brzmi: są złe, ponieważ nie są obsługiwane? Ale dlaczego nie są obsługiwane? Ponieważ nie są częścią specyfikacji? Ok, ale dlaczego nie są częścią specyfikacji? Jestem trochę rozczarowany tą odpowiedzią.
Josef Sábl
61
Nie jestem tutaj, aby dyskutować na temat „wielkich pytań”, takich jak dlaczego tu jesteśmy, jak to wszystko się zaczęło itp. Nie można zagwarantować obsługi skrótów na serwerach współużytkowanych i jest ona usuwana całkowicie następna ważna wersja. To wszystko, co musisz wiedzieć.
Oli
39
Obowiązkowe PHP to silnik szablonów. : P
Błąd składni
49
Krótkie tagi nie są wycofywane. Tylko krótkie znaczniki w stylu ASP.
Brian Lacy
46
W (bardzo bliskiej) przyszłości PHP 5.4 użycie <? = Będzie oddzielone od tego, czy short_open_tags są włączone czy wyłączone. <? = nie jest wycofywane, wręcz przeciwnie, jest obecnie uważane za podstawowy element języka.
Pan Griever,
175

Jestem zbyt lubi, <?=$whatever?>aby odpuścić. Nigdy nie miałam z tym problemu. Poczekam, aż ugryzie mnie w tyłek. Z całą powagą 85% (moich) klientów ma dostęp do php.ini w rzadkich przypadkach, gdy są oni wyłączani. Pozostałe 15% korzysta z głównych dostawców hostingu i praktycznie wszyscy mają ich włączonych. Kocham ich.

Paolo Bergantino
źródło
41
@B Seven Jeśli spróbujesz uniknąć wszelkich teoretycznych problemów, które mogą się pojawić, Twój kod będzie prawie na pewno nieefektywny i zawiera błędy. Dopóki grupa PHP nie zgodzi się na wycofanie krótkich tagów [nie tagów ASP], zmartwienie związane z ugryzieniem jest znacznie mniejsze, a potencjalne rozwiązanie znacznie prostsze, niż inne rzeczy, które możesz poświęcić na „naprawianie”.
SamGoody
18
jeśli cię gryzie, przejdź do lepszego hostingu
Lie Ryan
4
Naprawdę nie zgadzam się z nieużywaniem czegoś, ponieważ może nie być obsługiwane. Czy nie powinniśmy korzystać z innych funkcji, które mogą nie być obsługiwane na serwerze? MYSQL vs MYSQLI? Stopniowo będziesz marnować czas, pisząc długie tagi, aby uniknąć niewielkiej szansy spędzenia trochę czasu na zmianie na lepszego hosta.
Dean Or
2
@BSeven, Czy masz na myśli, że nie używasz żadnych rozszerzeń PHP oprócz domyślnie dostarczanych?
Pacerier,
143

Począwszy od PHP 5.4, skrót echa jest zagadnieniem odrębnym od krótkich znaczników, ponieważ skrót echa zawsze będzie włączony. To teraz fakt:

Tak więc sam skrót echa ( <?=) jest teraz bezpieczny.

dukeofgaming
źródło
19
Powiedziałbym, że to jedyny potrzebny „krótki tag”. <?phpmożna użyć na początku wszystkich plików klas, a następnie masz <?=do swoich widoków. win-win.
Xeoncross,
6
So the echo shortcut itself (<?=) is safe to use... o ile tylko potrzebujesz PHP 5.4. Szeroko rozpowszechniane aplikacje PHP (takie jak wordpress) nie mają luksusu wymagającego 5.4, a nawet oferowały obsługę PHP 4 do 2011 roku - pełne 7 lat po wydaniu PHP 5. Jeśli jesteś w miejscu takim jak Facebook, gdzie wszystkie instalacje twojego oprogramowania są obsługiwane bezpośrednio przez samą firmę, to wymaganie wsparcia 5.4 jest znacznie łatwiejsze niż jeśli pracujesz nad projektem takim jak wordpress.
Frank Farmer,
@dukeofgaming, Wow good catch, nie wiedział, że ich wersje SVN są dostępne w Internecie.
Pacerier,
82

Problem z całą tą dyskusją polega na wykorzystaniu PHP jako języka szablonów. Nikt nie twierdzi, że w plikach źródłowych aplikacji należy stosować tagi.

Jednak wbudowana składnia PHP pozwala na użycie jej jako potężnego języka szablonów, a szablony powinny być tak proste i czytelne, jak to możliwe. Wiele osób uważa, ż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 jedynym sposobem pisania szablonów.

Jedynym poprawnym argumentem PRZECIWKO użyciu krótkich tagów jest to, że nie są one obsługiwane na wszystkich serwerach. Komentarze na temat konfliktów z dokumentami XML są absurdalne, ponieważ prawdopodobnie nie powinieneś mieszać PHP i XML; a jeśli tak, powinieneś używać PHP do wyprowadzania ciągów tekstu. Bezpieczeństwo nigdy nie powinno stanowić problemu, ponieważ jeśli umieszczasz poufne informacje, takie jak poświadczenia dostępu do bazy danych, w plikach szablonów, to masz większe problemy!

Teraz, jeśli chodzi o obsługę serwerów, trzeba przyznać, że należy być świadomym ich platformy docelowej. 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 przyjmuje (i faktycznie zależy od tego), że będziemy dyktować wymagania dotyczące serwera. Często jestem odpowiedzialny za samodzielne konfigurowanie serwera.

I NIGDY nie współpracujemy z dostawcą hostingu, który nie daje nam absolutnej kontroli nad konfiguracją serwera - w takim przypadku moglibyśmy liczyć na znacznie więcej problemów niż tylko utratę obsługi krótkich tagów. To się po prostu nie zdarza.

Tak więc - zgadzam się, że użycie krótkich tagów powinno być dokładnie rozważone. Ale głęboko wierzę również, że ZAWSZE powinna to być opcja i że programista, który jest świadomy swojego środowiska, powinien swobodnie z nich korzystać.

Brian Lacy
źródło
6
Jeśli z jakiegoś powodu skonfigurowano apache do przesyłania plików .xml do mod_php, <? Xml sprawiałoby ból głowy z krótkimi tagami. Ale to oczywiście dziwna konfiguracja.
Frank Farmer,
3
Szablonów języka, które nie mogą być osadzone bez obejścia w niektórych rodzajach dokumentów wyjściowych jest wielkim niepowodzeniem. Jedynym powodem, dla którego nie powinienem mieć szablonu XML z kodem PHP i krótkimi znacznikami, jest to, że nie działa, a nie dlatego, że nie ma sensu.
Vinko Vrsalovic
8
Nie jest wielką porażką korzystanie z zalet PHP jako szybkiego i wygodnego języka szablonów. Jak powiedziałem wcześniej, jest to kwestia wyważenia zalet i wad oraz napisania kodu w sposób uwzględniający wybrane przez ciebie podejście. Nie odrzucaj kategorycznie prawidłowego podejścia tylko dlatego, że nie działa ono w jednym konkretnym scenariuszu (który można łatwo obejść).
Brian Lacy
5
Nie odrzucam kategorycznie żadnego poprawnego podejścia (patrz moja odpowiedź na pytanie). To ty kategorycznie odrzucasz PHP w XML, cytuję: „nie powinieneś mieszać PHP i XML”. Wielkim niepowodzeniem, o którym mówiłem, była decyzja o użyciu <?jako krótkiego znacznika, ponieważ prowadzi to do brzydkich obejść XML. To powiedziawszy, zgadzam się, że chodzi o rozważenie korzyści i wad oraz, że jeśli wiesz, co robisz, na pewno możesz to zrobić. Ale to nie <?jest dobry wybór.
Vinko Vrsalovic
3
Jestem trochę spóźniony na przyjęcie, ale naprawdę podoba mi się ta odpowiedź, która odzwierciedla moje doświadczenie z sytuacją. Chociaż w naszym biurze mamy spory w tej sprawie, mogę powiedzieć, że przy prawie codziennej pracy w php przez wiele lat, nigdy nie spotkałem się z tym problemem. Kiedy PHP jest używane do generowania XML, z mojego doświadczenia zawsze wynikało to w kontekście wysoce dynamicznej treści, która nigdy nie była bezpośrednio wzorowana na PHP, więc problem po prostu nigdy się nie pojawia.
redreinard
33

Krótkie tagi powracają dzięki Zend Framework wypychając „ PHP jako język szablonów ” w ich domyślnej konfiguracji MVC . Nie rozumiem, o co chodzi w debacie, większość oprogramowania, które wytworzysz w ciągu swojego życia, będzie działało na serwerze, który kontrolujesz ty lub twoja firma. Dopóki będziesz konsekwentny, nie powinno być żadnych problemów.

AKTUALIZACJA

Po sporo pracy z Magento , który używa długiej formy. W rezultacie przeszedłem na długą formę:

<?php and <?php echo

nad

<? and <?=

Wydaje się, że niewielka ilość pracy zapewnia interoperacyjność.

Jake McGraw
źródło
8
Jestem freelancerem i cały mój kod idzie na hosting współdzielony, więc nie mam żadnej kontroli! :)
MDCore
12
Jeśli masz wystarczającą liczbę klientów, którzy przeniosą się do twojego własnego coloc, hosting dzielony jest niepewny i niestabilny.
Jake McGraw,
2
Krótkie tagi, które przywracał Zend, najwyraźniej nie zostały złapane, ponieważ Zend używa długiej wersji: framework.zend.com/manual/en/zend.view.scripts.html
Gerry
3
@Gerry Przeczytałem to również niedawno, zobacz ostatni komentarz do tego wątku: Zaktualizuj
plik
2
Naprawdę powinieneś poprawić gramatykę w pierwszym zdaniu po aktualizacji, co w obecnej formie nie ma sensu.
redreinard
22

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

Dodatkową troską jest ból, który spowodowałby kodowanie wszystkiego za pomocą krótkich tagów, aby na końcu dowiedzieć się, że końcowy serwer hostingowy je wyłączył ...

Vinko Vrsalovic
źródło
Czy deklaracja XML i tak nie spowoduje zamieszania, jeśli włączone są krótkie_tagi?
MDCore,
Zamiast bezpośrednio wypisywać deklarację XML, PHP ma to naśladować. To naprawdę nie jest dobry obalenie.
moo
To nie jest obalenie czegokolwiek. Jest to jedyny faktyczny powód, który z kolei jest przyczyną innego powodu „hoster wyłącza”, oczywiście możesz go użyć, jeśli wiesz, co robisz, jak zawsze.
Vinko Vrsalovic
1
@macek: Jestem tego świadomy. To był tylko pierwszy przykład, o którym myślałem. Kolejne, co jeśli osadzisz PHP w pliku XML? Nie możesz tego zrobić bezpośrednio. I nie mów mi również o rozwiązaniu tego problemu, jestem tego świadomy. Chodzi o to, że PHP ma wiele sposobów na parsowanie pliku XML. Prawdopodobnie możesz je wszystkie odrzucić za pomocą obejść ( <?='<?xml') lub mówiąc „nie powinieneś tego robić”, ale to nie oznacza, że ​​fakt, że tak się dzieje, zniknie.
Vinko Vrsalovic
1
Jak krótkie tagi są uciążliwe, jeśli nie działają? jej jest bardzo proste do zrobienia i zastąpić większość <?=z <? echo . Wiele edytorów tekstu z łatwością poradzi sobie z robieniem tego tysiącom plików jednocześnie.
Yamiko,
20

Oto wspaniały schemat tego samego:

drzewo decyzyjne użycia <? =

Źródło: podobne pytanie dotyczące wymiany stosów inżynierii oprogramowania

Sumoanand
źródło
2
Opisuje, czy użyć krótkiego znacznika echa, a nie tego samego, co <?krótkie znaczniki wspomniane w pytaniu (chociaż używał tego samego ustawienia konfiguracji sprzed 5.4)
Alok
W rzeczywistości powinna to być odpowiedź, którą każdy może zrozumieć, choć okoliczności tak naprawdę nie są wyjaśnione, dlaczego w wielu przypadkach nie chcesz używać krótkich tagów (np. Nie można zmienić pliku php.ini na współdzielonym systemie hostingowym)
Björn K
14

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php zawiera wiele porad, w tym:

chociaż niektórzy uważają, że krótkie tagi i tagi stylu ASP są wygodne, są mniej przenośne i generalnie nie są zalecane.

i

pamiętaj, że jeśli osadzasz PHP w XML lub XHTML, będziesz musiał użyć <?php ?>tagów, aby zachować zgodność ze standardami.

i

Należy unikać używania krótkich tagów podczas tworzenia aplikacji lub bibliotek przeznaczonych do redystrybucji lub wdrażania na serwerach PHP, które nie są pod twoją kontrolą, ponieważ krótkie tagi mogą nie być obsługiwane na serwerze docelowym. W przypadku przenośnego, redystrybucyjnego kodu pamiętaj, aby nie używać krótkich tagów.

Oliver Charlesworth
źródło
14

Jeśli 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

Wygląda więc na to, że krótkie tagi są (a) dopuszczalne i (b) są tutaj. Na razie przynajmniej ...

James Alday
źródło
5
<?=nie jest uważany za krótki tag od 5.4
T0xicCode
12
  • Krótkie tagi nie są domyślnie włączone na niektórych serwerach WWW (hosty współdzielone itp.), Więc przenoszenie kodu staje się problemem, jeśli musisz przejść na jeden z nich.

  • Czytelność może stanowić problem dla niektórych. Wielu programistów może zauważyć, że <?phpprzyciąga wzrok jako bardziej oczywisty znacznik początku bloku kodu niż <?podczas skanowania pliku, szczególnie jeśli utkniesz w bazie kodu z HTML i PHP ściśle splecionymi.

ConroyP
źródło
2
Krótkie tagi są włączone w 95% serwerów sieciowych.
Paolo Bergantino
19
Nie kupuję argumentu „czytelność”. Jeśli używasz PHP jako języka szablonów, <?= $var ?>jest o wiele bardziej czytelny niż<?php echo $var ?>
Frank Farmer
2
@Paulo mogło się to zmienić od '08, ale instancje EC2 Ubuntu i Fedora z yum install i apt-get w wersjach PHP mają domyślnie wyłączone krótkie tagowanie
Doug Molineux
2
użyj pełnych tagów, a będziesz mieć 100% :)
Elvis Ciotti
1
@FrankFarmer, myślę, że porównuje ten bez echa. <?vs <?php.
Pacerier,
11

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

brunoais
źródło
5

Przeczytałem tę stronę po poszukiwaniu informacji na ten temat i uważam, że nie wspomniano o jednym głównym problemie: lenistwo a konsekwencja. „Prawdziwe” tagi dla PHP to <? Php i?>. Dlaczego? Nie obchodzi mnie to. Dlaczego miałbyś chcieć użyć czegoś innego, skoro są one wyraźnie dla PHP? <% i%> oznaczają dla mnie ASP, a <skrypt ..... oznacza Javascript (w większości przypadków). Więc dla spójności, szybkiego uczenia się, przenośności i prostoty, dlaczego nie trzymać się standardu?

Z drugiej strony zgadzam się, że krótkie tagi w szablonach (i TYLKO w szablonach) wydają się przydatne, ale problem polega na tym, że poświęciliśmy tyle czasu na omawianie ich tutaj, że prawdopodobnie zajęłoby to bardzo dużo czasu tyle czasu wpisując dodatkowe trzy znaki „php” !!

Chociaż posiadanie wielu opcji jest przyjemne, nie jest wcale 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ć <JS lub <skrypt .... lub <% lub <? JS .... czy to by było pomocne? W przypadku PHP kolejność analizowania jest na korzyść pozwalania na te rzeczy, ale język na wiele innych sposobów nie jest elastyczny: rzuca uwagi lub błędy na najmniejszą niespójność, jednak często używane są krótkie tagi. A gdy na serwerze, który ich nie obsługuje, używane są krótkie tagi, ustalenie, co jest nie tak, może zająć bardzo dużo czasu, ponieważ w niektórych przypadkach nie występuje błąd.

Wreszcie, nie sądzę, że problem stanowią krótkie tagi: istnieją tylko dwa logiczne typy bloków kodu PHP: 1) zwykły kod PHP, 2) echa szablonu. W przypadku tych pierwszych mocno wierzę, że tylko <? Php i?> Powinny być dozwolone, aby zachować wszystko spójne i przenośne. W tym drugim przypadku metoda <? = $ Var?> Jest brzydka. Dlaczego tak musi być? Dlaczego nie dodać czegoś bardziej logicznego? <? php $ var?> To by nic nie zrobiło (i tylko w najbardziej odległych możliwościach mogłoby kolidować z czymś), a to z łatwością zastąpiłoby niezręczną składnię <? =. Lub jeśli jest to problem, być może mogliby użyć <? Php = $ var?> I nie martwić się niespójnościami.

W miejscu, w którym istnieją 4 opcje otwierania i zamykania tagów oraz losowego dodawania specjalnego znacznika „echo”, PHP może również mieć flagę „niestandardowe tagi otwieranie / zamykanie” w php.ini lub .htaccess. W ten sposób projektanci mogą wybrać ten, który najbardziej im się podoba. Ale z oczywistych powodów to przesada. Dlaczego więc dopuszczać opcje 4+?

Daniel Ross
źródło
4

Dobrze jest ich używać podczas pracy ze strukturą MVC lub CMS, które mają osobne pliki widoków.
Jest szybki, mniej kodu, nie jest mylący dla projektantów. Upewnij się tylko, że konfiguracja serwera pozwala na ich użycie.

Greg
źródło
4

Trochę inna jest sytuacja przy opracowywaniu aplikacji CodeIgniter . CodeIgniter wydaje się używać skrótów za każdym razem, gdy PHP jest używane w szablonie / widoku, w przeciwnym razie w modelach i kontrolerach zawsze używa długich znaczników. Nie jest to twarda i szybka reguła w frameworku, ale w przeważającej części frameworka i wiele źródeł innych zastosowań jest zgodnych z tą konwencją.

Moje dwa centy? Jeśli nigdy nie planujesz uruchamiać kodu w innym miejscu, użyj go, jeśli chcesz. Wolałbym nie przeprowadzać masowych poszukiwań i zastępować, kiedy zdaję sobie sprawę, że to głupi pomysł.

patricksweeney
źródło
4

<?jest domyślnie wyłączony w nowszych wersjach. Możesz włączyć to tak, jak opisano Włączanie krótkich tagów w PHP .

AnkTech Devops
źródło
Jest również domyślnie wyłączony w starszych wersjach, prawda?
Pacerier,
3

Ludzie IMHO, którzy używają krótkich tagów, często zapominają uciec od tego, co odbijają. Byłoby miło mieć silnik szablonów, który domyślnie ucieka. Wierzę, że Rob A napisał szybki hack, aby uciec przed krótkimi tagami w aplikacjach Zend Frameworks. Jeśli lubisz krótkie tagi, ponieważ ułatwia to czytanie PHP. Czy Smarty może być lepszym rozwiązaniem?

{$myString|escape}

dla mnie to wygląda lepiej niż

<?= htmlspecialchars($myString) ?> 
Adrian Judd
źródło
10
Dla większości programistów PHP druga opcja ma większy sens niż pierwsza, po prostu dlatego, że jest to znana funkcja PHP, którą znamy, podczas gdy pierwszą opcją jest pseudo szablonowy kod, którego musimy nauczyć się na PHP. PHP jest już językiem szablonów, dodając do niego inny język szablonów, tak jak Smarty jest redundantnym IMO.
Bug Magnet
3
Twig to silnik szablonów z domyślnym włączaniem
mateusza
3

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

Szybsze pisanie

MDCore powiedział:

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

Tak to jest. Zaoszczędzasz konieczności wpisywania 7 znaków * X razy w swoich skryptach.

Jednak, kiedy skrypt zajmuje godzinę, 10 godzin lub więcej, aby zaprojektować, rozwinąć i napisać, jak istotne jest, aby kilka sekund nie wpisywało tych 7 znaków tu i tam przez czas trwania skryptu?

W porównaniu do możliwości niektórych podstawowych lub wszystkich skryptów, które nie działają, jeśli krótkie tagi nie są włączone lub są włączone, ale aktualizacja lub ktoś zmieniający konfigurację pliku / serwera ini zatrzymuje je, inne potencjały.

Niewielka korzyść, którą zyskujesz, nie jest prawie równa z ciężkością potencjalnych problemów, to znaczy, że twoja strona nie działa, lub gorzej, tylko niektóre jej części nie działają, a zatem 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. Chociaż <?=nie jest trudny do odczytania, nie jest mi znany i dlatego nie jest łatwiejszy do odczytania .

A czy przy podzieleniu programisty front-end / back-end (jak w przypadku większości firm) programista front-end pracujący na tych szablonach byłby bardziej znany, wiedząc, że <?=jest to równoznaczne z „otwartym tagiem PHP i echem”?
Powiedziałbym, że najbardziej byłoby wygodniej z logicznym. To znaczy, wyraźny otwarty tag PHP, a następnie to, co się dzieje „echo” - <?php echo.

Ocena ryzyka
Problem = cały skrypt lub podstawowe skrypty nie działają;

Potencjał problemu jest bardzo niski + dotkliwość wyniku jest bardzo wysoka = wysokie ryzyko

Wniosek

Zaoszczędzisz kilka sekund tu i tam, bez konieczności wpisywania kilku znaków, ale ryzykujesz za to wiele, a także prawdopodobnie stracisz czytelność.

Przednia lub tylna end koderzy znane ze <?=są bardziej prawdopodobne, aby zrozumieć <?php echo, jak oni standardowych rzeczy PHP - Standardowy <?phptagu otwarte i bardzo dobrze znany „echo”.
(Nawet kodery front-endowe powinny znać „echo” lub po prostu nie będą pracować na żadnym kodzie obsługiwanym przez framework).

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

James
źródło
Nie ma to nic wspólnego z pisaniem. Jest krótszy, a zatem może być łatwiejszy do odczytania . Osoba przyzwyczajona do czytania <?=będzie czytać <?=łatwiej niż osoba przyzwyczajona do <?php echoczytania <?php echo.
Pacerier,
@Pacerier Shorter nie jest po prostu = łatwiejszy do odczytania. Wszyscy jesteśmy różni. Co masz na myśli to, że jest łatwiejsze do odczytania dla ciebie . Jak wpisuję swoją odpowiedź, ponieważ jestem przyzwyczajony do <?phptego, że w całym kodzie wiele razy jest mi bardziej znany niż <?=- znajomość ułatwia rzeczy - niekoniecznie lepiej.
James
Nie, nie jestem porównując Ty i ja, mówię osoba używany do czytania <?=będzie czytać <?=lepiej niż osoba używany do czytania <?php echolektury <?php echo. Oznacza to, że jeśli mamy dwie identyczne kopie osoby X i zmieniamy je tylko w aspekcie, w którym jedna jest przyzwyczajona do czytania <?=, a druga do czytania <?php echo, pierwsza kopia może osiągnąć wartość czytelności xpodczas czytania przy użyciu pożądanej składni, podczas gdy druga kopia może osiągnąć wartość czytelności ypodczas odczytu jego pożądanej składni, gdzie x >= y.
Pacerier
Nie, brakuje ci sensu. Mam na myśli potencjał systemu, który nie ma nic wspólnego z żadną konkretną osobą. Można powiedzieć, że ludzie przyzwyczajeni do pisania na klawiaturze qwerty będą pisać szybciej przy użyciu qwerty, podczas gdy ludzie przyzwyczajeni do pisania przy użyciu dvorak będą pisać szybciej przy użyciu dvorak, ale fakt nie zmienia faktu, że oba systemy mają inny potencjał.
Pacerier,
3

Spojrzmy prawdzie w oczy. PHP jest brzydki jak diabli bez krótkich tagów.

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

php_flag short_open_tag on
Jimmer
źródło
3
Fałszywe. Czasami serwer jest ustawiony tak, by odmawiać jakiegokolwiek nadpisywania, proszę pana.
Alfabravo,
17
To prawda, ale jeśli twój host nie pozwala ci na przesłonięcie htaccess, naprawdę potrzebujesz nowego hosta! :)
Brian Lacy
1
nie działa na interfejsie wiersza polecenia i php_flag nie jest obsługiwana przez cały czas
Elvis Ciotti
3

Aby uniknąć problemów związanych z przenośnością, uruchamiaj tagi PHP za pomocą, <?phpa jeśli plik PHP to wyłącznie PHP, bez HTML, nie musisz używać tagów zamykających.

Kumar
źródło
2
  • Krótkie tagi są dopuszczalne w przypadkach, gdy masz pewność, że serwer będzie je obsługiwał i że 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ż tak naprawdę nie jest tak źle.

Powiedziawszy to, mój przyjaciel powiedział to na poparcie alternatywnych standardowych tagów w stylu asp, takich jak <%zamiast <?, co jest ustawieniem w php.ini o nazwie asp_tags. Oto jego uzasadnienie:

... arbitralne konwencje powinny zostać znormalizowane . Oznacza to, że za każdym razem, gdy mamy do czynienia z zestawem możliwości o jednakowej wartości - takich jak dziwna interpunkcja, której nasz język programowania powinien używać do wyznaczania siebie - powinniśmy wybrać jeden standardowy sposób i trzymać się go. W ten sposób zmniejszamy krzywą uczenia się wszystkich języków (lub cokolwiek innego, czego dotyczy konwencja).

Brzmi dla mnie dobrze, ale nie sądzę, aby ktokolwiek z nas mógł okrążyć wagony wokół tej przyczyny. W międzyczasie trzymałbym się wszystkiego <?php.

stereoscott
źródło
2

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

  • Krótkie tagi ASP PHP <% … %>zniknęły
  • Krótkie karty PHP <? … ?>są nadal dostępne, jeślishort_open_tag jest ustawione na true. To jest domyślne.
  • Od PHP 5.4 tagi krótkiego wydruku<?=… ?>zawsze włączone, niezależnie od short_open_tagustawienia.

Dobra riddance do pierwszego, ponieważ kolidował z innymi językami.

Teraz nie ma powodu, aby nie używać tagów z krótkim nadrukiem, poza osobistymi preferencjami.

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

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

Manngo
źródło
1
O ile się nie mylę, twój pierwszy punkt jest błędny. Dokument mówi, że znaczniki ASP, a nie krótkie znaczniki PHP, zniknęły z wersji PHP 7.0.0.
zreformowany
@reformed Masz absolutną rację. Zmienię swoją odpowiedź. Dzięki
Manngo,
1

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

Nawet jeśli skrócisz echo htmlspecialchars()doh() , to wciąż problem, że trzeba pamiętać, aby dodać go niemal za każdym razem (i stara się śledzić, które dane jest wstępnie uciekł, która jest Niecytowany-ale-nieszkodliwy sprawia tylko błędy bardziej prawdopodobne).

Używam domyślnie bezpiecznego silnika szablonów i zapisuje <?phpdla mnie tagi.

Kornel
źródło
7
Jeśli zauważysz, że wpisujesz „<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 razy dziennie, możesz utworzyć funkcję skrótu o nazwie„ h ”, tak jak Rails ma…” < ? = h ($ text)?> ”jest o wiele bardziej czytelny podczas skanowania szablonu.
Alexander Malfait
1
Rzeczywiście jest to lepsze, ale z silnikiem szablonów może to być po prostu $ {tekst} lub coś takiego (i nie musisz pamiętać, aby dodać h ())
Kornel
7
Sam PHP to silnik szablonowy. Kiedy przestajesz używać krótkich tagów, zaczyna to być zły silnik szablonów, ponieważ staje się zbyt gadatliwy.
Josef Sábl
1
@Alexander Malfait to dobra wskazówka. Ale <? = Nie jest potrzebne. Możesz po prostu sprawić, by funkcja odbijała ciąg zamiast zwracać, więc wtedy napiszesz <? Php h ('hello')?> Czy nie robimy tego, kiedy de i18n? <? php _e ('')?> nie jest taki zły.
VladFr
1

<?php ?>są znacznie lepsze w użyciu, ponieważ twórcy tego języka programowania masowo zaktualizowali swój język podstawowy. Możesz zobaczyć różnicę między krótkimi i długimi tagami.

Krótkie tagi zostaną podświetlone na jasno czerwone, a dłuższe - ciemniejsze!

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

Skrypty M50
źródło
1

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

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

Konwertuj <?(z końcowym odstępem) na <?php(zachowując końcowy odstęp):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
Fatih Akgun
źródło
1

Krótki tag jest zawsze dostępny w php. Więc nie potrzebujesz echa pierwszej instrukcji w skrypcie

przykład:

    $a =10;
    <?= $a;//10 
    echo "Hellow";//
    echo "Hellow";

   ?>

Nagle musisz użyć jednego skryptu php, a następnie możesz go użyć. przykład:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>
GaziAnis
źródło
1

Od 2019 r. Nie zgadzam się z niektórymi odpowiedziami tutaj. Polecam używać długich tagów

<?php /* code goes here */ ?>

lub krótkie znaczniki echa

<?= /* code goes here */ ?>

Powód: są zalecane przez podstawowy standard kodowania PSR-1

Inne krótkie tagi, takie jak, <? /* code goes here */ ?>nie są zalecane.

Specyfikacja mówi:

Kod PHP MUSI używać długich znaczników lub krótkich ech; NIE WOLNO używać innych odmian tagów .

Blackbam
źródło
1

3 tagi są dostępne w php:

  1. długi znacznik, który <?php ?>nie wymaga kierowania żadnymi skonfigurowanymi
  2. short_open_tag, który jest <? ?> dostępny, jeśli włączona jest opcja short_open_tag w php.ini
  3. skróć znacznik, <?= ponieważ php 5.4.0 jest zawsze dostępny

z php 7.0.0 asp i tag skryptu zostały usunięte

GaziAnis
źródło
To nie odpowiada na pytanie.
RalfFriedl
-5

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

coderGeek
źródło
4
Widziałem inne posty na blogu, które mówią, że nie będą przestarzałe, tylko krótkie tagi w stylu ASP.
MDCore,
22
Wygląda na to, że ta odpowiedź jest niepoprawna, zgodnie z tym linkiem ze spotkania programistów PHP: php.net/~derick/…
Charles,
7
DLACZEGO oni są tacy źli, dlaczego? Wszyscy są tak pewni siebie, że są baaaaaad, ale nikt nie mówi dlaczego.
Josef Sábl
6
FAŁSZYWE. Wycofują tagi <%%>, tak jak powinny. Służą tylko celom, ale dezorientują. <? ?> nie wpłynie to na tagi; ale oczywiście są one nadal konfigurowalne dla poszczególnych serwerów i zawsze powinieneś być świadomy wymagań platformy docelowej.
Brian Lacy
6
Informacje te wydają się nieprawidłowe i wprowadzające w błąd i powinny zostać poprawione przez autora.
tex