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

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

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

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

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

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

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

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

• SVN Revision от Расмуса Лердорфа
• Обсуждение рассылки

Таким образом, сам ярлык эха ( <?= ) Безопасен.

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

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

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

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

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

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

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

ОБНОВИТЬ

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

 <?php and <?php echo 

над

 <? and <?= 

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

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

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

Ниже приведена замечательная схема:

Источник: аналогичный вопрос об обмене стеками программ

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

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

а также

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

а также

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 php_flag short_open_tag on 

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

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

 {$myString|escape} 

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

 <?= htmlspecialchars($myString) ?> 

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

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

MDCore сказал:

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

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

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

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

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

Легче читать

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

Преобразовать <? (без конечного пробела) до <?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' 

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

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

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

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

Short tags will be highlighted as light red while the longer ones are highlighted darker!

However, echoing something out, for example: <?=$variable;?> is fine. But prefer the longer tags. <?php echo $variable;?>

No, and they're being phased out by PHP 6 so if you appreciate code longevity, simply don't use them or the <% ... %> tags.