Являются ли PHP короткие теги приемлемыми для использования?

Здесь информация в соответствии с официальной документацией:

Существует четыре разные пары открытие и закрытие тегов, которые могут быть используется в PHP. Два из них, <?php ?>и <script language="php"> </script>, всегда доступны. Два других короткие теги и теги стиля ASP, и может быть включено и выключено Файл конфигурации php.ini. Как таковой, в то время как некоторые люди находят короткие теги и Теги стиля ASP удобны, они менее портативный, а вообще не Рекомендуется.

По моему опыту большинство серверов имеют короткие теги. Typing

<?=

гораздо удобнее, чем печатать

<?php echo 

Удобство программистов является важным фактором, поэтому почему они не рекомендуются?

Ответ 1

Они не рекомендуются, потому что это PITA, если вам когда-либо нужно переместить свой код на сервер, на котором он не поддерживается (и вы не можете его активировать). Как вы говорите, многие общие хосты поддерживают короткие тэги, но "лоты" - не все. Если вы хотите поделиться своими сценариями, лучше всего использовать полный синтаксис.

Я согласен, что <? и <?= проще для программистов, чем <?php и <?php echo, но можно выполнять массовую находку и замену, если вы используете одну и ту же форму каждый раз (и не зажимайте в пространствах (например: <? php или <? =)

Я не покупаю читаемость как причину вообще. У большинства серьезных разработчиков есть возможность выделения синтаксиса, доступного для них.

Как упоминает ThiefMaster в комментариях, с PHP 5.4, теги <?= ... ?> поддерживаются везде, независимо от настроек shorttags. Это должно означать, что они безопасны для использования в переносном коде, но это означает, что тогда существует зависимость от PHP 5.4+. Если вы хотите поддерживать pre-5.4 и не можете гарантировать короткие тэги, вам все равно придется использовать <?php echo ... ?>.

Кроме того, вам нужно знать, что теги теги ASP и lt;%,% > , <% = и script удалены из PHP 7. Поэтому, если вы хотите поддерживать долговременный переносимый код и хотите перейти на самые современные инструменты, подумайте об изменении этих частей кода.

Ответ 2

Я слишком люблю <?=$whatever?>, чтобы отпустить его. Никогда не было проблем с этим. Я подожду, пока он не укусит меня в задницу. Серьезно, 85% (моих) клиентов имеют доступ к php.ini в редком случае, когда они отключены. Другие 15% используют основные хостинг-провайдеры, и практически все они имеют возможность их включения. Я люблю их.

Ответ 4

Проблема с этим обсуждением заключается в использовании PHP в качестве языка шаблонов. Никто не утверждает, что теги должны использоваться в исходных файлах приложения.

Однако встроенный в PHP синтаксис позволяет использовать его в качестве мощного языка шаблонов, а шаблоны должны быть максимально простыми и понятными. Многим было проще использовать гораздо более медленный, надстрочный шаблонный движок, такой как Smarty, но для тех пуристов среди нас, которые требуют быстрого рендеринга и чистой базы кода, PHP - единственный способ писать шаблоны.

ТОЛЬКО действительный аргумент ПРОТИВ использования коротких тегов заключается в том, что они не поддерживаются на всех серверах. Комментарии о конфликтах с документами XML смехотворны, потому что вы, вероятно, не должны смешивать PHP и XML; и если да, вы должны использовать PHP для вывода строк текста. Безопасность никогда не должна быть проблемой, потому что если вы размещаете конфиденциальную информацию, такую ​​как учетные данные доступа к базе данных внутри файлов шаблонов, тогда у вас есть больше проблем!

Теперь, что касается проблемы поддержки сервера, то, разумеется, нужно знать о своей целевой платформе. Если общий хостинг является вероятной целью, следует избегать коротких тегов. Но для многих профессиональных разработчиков (таких как я) клиент подтверждает (и действительно, зависит от факта), что мы будем диктовать требования к серверу. Часто я сам отвечаю за настройку сервера.

И мы НИКОГДА не работаем с хостинг-провайдером, который не дает нам абсолютного контроля над конфигурацией сервера - в таком случае мы могли бы рассчитывать на запуск гораздо больше проблем, чем просто потерять поддержку коротких тегов. Этого просто не бывает.

Итак, да, я согласен с тем, что использование коротких тегов следует тщательно взвешивать. Но я также твердо убежден, что он должен ВСЕГДА быть вариантом, и что разработчик, который знает о своей среде, должен быть свободен в использовании.

Ответ 5

Короткие теги возвращаются благодаря Zend Framework, нажимая PHP как язык шаблонов в своей конфигурации MVC по умолчанию. Я не понимаю, о чем идет речь, большая часть программного обеспечения, которое вы будете производить в течение вашей жизни, будет работать на сервере, которым вы или ваша компания будете управлять. Пока вы держите себя в курсе, проблем не должно быть.

UPDATE

После выполнения довольно большой работы с Magento, который использует длинную форму. В результате я переключился на длинную форму:

<?php and <?php echo

над

<? and <?=

Похоже на небольшой объем работы, обеспечивающий интероперабельность.

Ответ 6

Из-за путаницы он может генерировать объявления XML. Многие люди согласны с вы, однако.

Еще одна проблема - боль, которую она создала, чтобы закодировать все с короткими тегами только, чтобы узнать в конце, что конечный сервер хостинга отключил их...

Ответ 8

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php содержит много советов, в том числе:

в то время как некоторые люди находят короткие теги и Теги стиля ASP удобны, они менее переносимыми, и, как правило, не рекомендуется.

и

обратите внимание, что если вы встраиваете PHP в XML или XHTML вам нужно будет используйте теги <?php ?>, чтобы оставаться совместимый со стандартами.

и

Следует избегать использования коротких тегов при разработке приложений или библиотеки, предназначенные для перераспределение или развертывание на PHP серверов, которые не находятся под вашим потому что короткие теги могут не быть поддерживается на целевом сервере. Для переносимый, распространяемый код, не используйте короткие теги.

Ответ 9

В случае, если кто-то все еще обращает внимание на это... С PHP 5.4.0 Alpha 1 <?= всегда доступен:

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

Итак, похоже, что короткие теги (а) приемлемы и (б) здесь, чтобы остаться. На данный момент по крайней мере...

Ответ 10

  • Короткие теги не включаются по умолчанию в некоторых веб-серверах (общие хосты и т.д.), поэтому переносимость кода становится проблемой, если вам нужно перейти к одному из них.

  • Чтение может быть проблемой для некоторых. Многие разработчики могут обнаружить, что <?php бросается в глаза как более очевидный маркер начала кода, чем <? при сканировании файла, особенно если вы застряли с базой кода с HTML и PHP тесно взаимосвязаны.

Ответ 11

Примечание. Начиная с PHP 5.4, короткий тег <?= теперь всегда доступен.

Ответ 12

Я прочитал эту страницу после поиска информации по этой теме, и я чувствую, что не упоминалась одна серьезная проблема: лень или последовательность. "Реальные" теги для PHP - это & ​​lt;? Php и? > . Зачем? Мне все равно. Почему вы хотите использовать что-то еще, когда это ясно для PHP? <% и% > средний ASP для меня, и < script..... означает Javascript (в большинстве случаев). Поэтому для обеспечения последовательности, быстрого обучения, мобильности и простоты, почему бы не придерживаться стандарта?

С другой стороны, я согласен с тем, что короткие теги в шаблонах (и ТОЛЬКО в шаблонах) кажутся полезными, но проблема в том, что мы просто потратили так много времени, обсуждая это здесь, что, вероятно, потребуется очень много времени, чтобы фактически потратили впустую много времени, набрав лишние три символа "php"!!

Несмотря на то, что есть много вариантов, это не совсем логично, и это может вызвать проблемы. Представьте, что если каждый язык программирования допускает 4 или более типов тегов: Javascript может быть < JS или < script.... или <% или <? JS.... было бы полезно? В случае PHP порядок разбора, как правило, в пользу разрешения этих вещей, но язык во многих других отношениях не является гибким: он бросает уведомления или ошибки при малейшей несогласованности, но короткие теги используются часто. И когда короткие теги используются на сервере, который их не поддерживает, может потребоваться очень много времени, чтобы выяснить, что не так, поскольку в некоторых случаях ошибка не указана.

Наконец, я не думаю, что здесь есть короткие теги: существует только два логических типа блоков кода PHP: 1) обычный PHP-код, 2) эхо-код шаблона. Для первого я твердо верю, что только < php и → должно быть разрешено просто сохранить все согласованное и портативное. Для последнего, < < < > $= & var; > метод уродливый. Почему так должно быть? Почему бы не добавить что-то более логичное? <? php $var → Это не сделало бы ничего (и только в самых отдаленных возможностях могло бы оно вступать в конфликт с чем-то), и это могло бы легко заменить неловкий синтаксис <? =. Или, если это проблема, возможно, они могут использовать <? Php = $var? > вместо этого, и не беспокоиться о несоответствиях.

В точке, где есть 4 варианта для открывающих и закрывающих тегов и случайного добавления специального тега "эхо", PHP может также иметь флаг пользовательских открывающих/закрывающих тегов в php.ini или .htaccess. Таким образом, дизайнеры могут выбрать тот, который им больше нравится. Но по очевидным причинам это излишне. Итак, почему допустимы 4+ варианта?

Ответ 13

Одна ситуация, которая немного отличается, заключается в разработке приложения CodeIgniter. CodeIgniter, кажется, использует shorttags всякий раз, когда PHP используется в шаблоне/представлении, иначе модели и контроллеры всегда используют длинные теги. Это не сложное и быстрое правило в рамках, но по большей части структура и много источников из других приложений следует этому соглашению.

Мои два цента? Если вы никогда не планируете запускать код в другом месте, используйте их, если хотите. Я бы предпочел не делать массовый поиск и заменять, когда я понимаю, что это была глупая идея.

Ответ 14

Посмотрим правде в глаза. PHP уродливый, как черт, без коротких тегов.

Вы можете включить их в файле .htaccess, если вы не можете добраться до php.ini:

php_flag short_open_tag on

Ответ 16

Хорошо использовать их, когда вы работаете с инфраструктурой MVC или CMS, которые имеют отдельные файлы представлений.
Это быстро, меньше кода, не путайте для дизайнеров. Просто убедитесь, что ваша конфигурация сервера позволяет использовать их.

Ответ 17

  • Короткие теги приемлемы для использования в тех случаях, когда вы уверены, что сервер будет поддерживать его и что ваши разработчики поймут его.
  • Многие серверы не поддерживают его, и многие разработчики поймут его, увидев его один раз.
  • Я использую полные теги для обеспечения переносимости, поскольку это действительно не так уж плохо.

С учетом сказанного мой друг сказал об этом в поддержку альтернативных стандартизованных тегов стиля asp, таких как <%, а не <?, который является параметром в php.ini, называемом asp_tags. Вот его рассуждения:

... произвольные соглашения должны быть стандартизированный. То есть, каждый раз, когда мы столкнулся с множеством возможностей, которые все равны - например, что странная пунктуация нашего программирования язык должен использоваться для демаркации сам - мы должны выбрать один стандарт и придерживаться его. Таким образом, мы уменьшить кривую обучения всех языков (или что бы то ни было конвенция относится к).

Звучит неплохо для меня, но я не думаю, что кто-то из нас может окружить вагоны вокруг этой причины. Тем временем я буду придерживаться полного <?php.

Ответ 18

Люди ИМХО, которые используют короткие теги, часто забывают избегать того, что они повторяют. Было бы неплохо иметь механизм шаблонов, который по умолчанию отключается. Я считаю, что Rob A написал быстрый хак, чтобы избежать коротких тегов в приложениях Zend Framework. Если вам нравятся короткие теги, потому что это упрощает чтение PHP. Тогда может ли Smarty быть лучшим вариантом?

{$myString|escape}

для меня, который выглядит лучше, чем

<?= htmlspecialchars($myString) ?> 

Ответ 19

Чтобы избежать проблем с переносимостью, запустите PHP-теги с помощью <?php, и если ваш PHP файл является чисто PHP, без HTML, вам не нужно использовать закрывающие теги.

Ответ 20

Нужно спросить, какой смысл использовать короткие теги.

Быстрее для ввода

MDCore сказал:

<?= гораздо удобнее, чем печатать <?php echo

Да, это так. Вы сохраняете, чтобы набирать 7 символов * X раз по всем вашим скриптам.

Однако, когда a script занимает час, или 10 часов или более, чтобы проектировать, разрабатывать и писать, насколько уместны несколько секунд времени, не набирая эти 7 символов здесь и там на протяжении всего времени script?

По сравнению с потенциалом для некоторых основных или всех сценариев, которые не работают, если короткие теги не включены или включены, но обновление или кто-то, изменяющий конфигурацию ini file/server, останавливает их работу, другие возможности.

Небольшое пособие, которое вы получаете, не приближается к перевесу тяжести потенциальных проблем, т.е. ваш сайт не работает, или, что еще хуже, только его части не работают и, таким образом, головная боль разрешается.

Легче читать

Это зависит от знакомства. Я всегда видел и использовал <?php echo. Так что пока <?= нетрудно прочитать, это мне не знакомо и, следовательно, не так легко читать.

И с разделением разработчиков переднего и заднего конца (как и в большинстве компаний) разработчик front-end, работающий над этими шаблонами, будет более знаком, зная, что <?= равен "PHP open tag и echo"?
Я бы сказал, что больше всего было бы более комфортно с более логичным. То есть явный открытый PHP-тег, а затем то, что происходит "эхо" - <?php echo.

Оценка риска
Проблема = целые сценарии сайта или ядра не работают;

Потенциал проблемы очень низкий + серьезность результата очень высокая = высокий риск

Заключение

Вы сохраняете несколько секунд здесь и не должны набирать несколько символов, но рискуете многого для этого, а также, вероятно, потеряете удобочитаемость.

Кодеры Front или back end, знакомые с <?=, с большей вероятностью понимают <?php echo, поскольку они являются стандартными вещами PHP - стандартным <?php открытым тегом и очень хорошо известным "эхом".
(Даже кодировщики переднего конца должны знать "эхо" или они просто не будут работать над любым кодом, обслуживаемым каркасом).

В то время как обратное не так вероятно, кто-то вряд ли логически выводит, что знак равенства на коротком теге PHP является "эхом".

Ответ 21

Преобразуйте <? (без конечного пробела) в <?php (с конечным пространством):

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

Преобразуйте <? (с конечным пространством) в <?php (сохраняя конечное пространство):

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

Ответ 22

Я думал, что стоит упомянуть, что в PHP 7:

  • Короткие ASP-теги PHP <% … %> пропали
  • Короткие вкладки PHP <? … ?> по-прежнему доступны, если для short_open_tag установлено значение true. Это значение по умолчанию.
  • Начиная с PHP 5.4, короткие печать тегов <?=… ?> всегда включены, независимо от настройки short_open_tag.

Хорошее избавление от первого, поскольку оно мешает другим языкам.

Теперь нет никаких причин не использовать короткие ярлыки для печати, кроме личных предпочтений.

Конечно, если вы пишете код, совместимый с унаследованными версиями PHP 5, вам нужно будет придерживаться старых правил, но помните, что все, что раньше, чем PHP 5.6, теперь не поддерживается.

Видеть: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Ответ 23

Если вы заботитесь о XSS, тогда вы должны использовать <?= htmlspecialchars(…) ?> большую часть времени, поэтому короткий тег не делает большой разница.

Даже если вы сократите echo htmlspecialchars() до h(), это все равно проблема, которую вы должны помнить, чтобы добавлять ее почти каждый раз (и пытаться отслеживать, какие данные предварительно экранированы, что не гарантировано, но безвредно только делает ошибки более вероятными).

Я использую механизм шаблонов, который по умолчанию защищен и записывает теги <?php для меня.

Ответ 24

<?php ?> гораздо лучше использовать, поскольку разработчики этого языка программирования значительно обновили свой основной язык. Вы можете увидеть разницу между короткими тегами и длинными тегами.

Короткие теги будут подсвечиваться как светло-красный, а более длинные - темнее!

Однако, повторяя что-то, например: <?=$variable;?> все в порядке. Но предпочитайте более длинные теги. <?php echo $variable;?>

Ответ 25

Короткие метки всегда доступны в php.   Так что вам не нужно повторять первое утверждение в вашем скрипте

Пример:

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

   ?>

Внезапно вам нужно использовать для одного сценария PHP, то вы можете   используй это.   Пример:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>

Ответ 26

С 2019 года я не согласен с некоторыми ответами здесь. Я рекомендую использовать длинные теги

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

или короткие теги эха

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

Причина: они рекомендованы базовым стандартом кодирования PSR-1

Другие короткие теги, такие как <? /* code goes here */ ?>, не рекомендуются.

В спецификации сказано:

PHP-код ДОЛЖЕН использовать длинные теги или короткое эхо теги; он НЕ ДОЛЖЕН использовать другие варианты тегов.

Ответ 27

3 тега доступны в php:

  1. длинный тег, который <?php ?> не нужно указывать для любого настроенного
  2. short_open_tag, который <? ?> доступен, если опция short_open_tag в php.ini включен
  3. сократить тег <?= начиная с php 5.4.0, он всегда доступен

из php 7.0.0 убраны asp и скрипт