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

522

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

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

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

<?=

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

<?php echo 

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

MDCore
источник
61
Чтобы ответить на этот вопрос why, я бы процитировал руководство по сертификации Zend PHP 5: «Короткие теги были некоторое время стандартом в мире PHP, однако они имеют главный недостаток - конфликтовать с заголовками XML и, следовательно, имеют упал на обочине ".
Пушистый
7
Каков случай использования, когда возникает эта проблема, означает ли это, что разработчикам трудно создавать XML с использованием PHP?
Jon Z
9
Допустим, у вас есть XML-документы, которые вы хотите сделать общедоступными, но вы хотите, чтобы документы были разбираться по php по любой причине, поэтому вы делаете синтаксический анализ в .xml вашим браузером. Вы используете короткие теги, чтобы они были включены, и вдруг документ XML анализируется через заголовки XML, что приводит к поломке. Сводил меня с ума, пытаясь понять это давно. С тех пор, как короткие коды были отключены на любом сервере, на котором я работаю, и любая команда, с которой я работал, вынуждена была прибегнуть к не короткому коду
thenetimp
43
Начиная с PHP 5.4.0, директива short_open_tag не содержит тега echo <?= $example;?> ! Это очень важно, так как использование всех других коротких тегов считается бесполезным. В любом случае, использование короткого тега эха теперь приветствуется. Это обеспечивает более гладкую и аккуратную кодовую базу - esp. в просмотр файлов. Так что для PHP> = 5.4.0 <?= ?> можно использовать без настройки short_open_tag . Пожалуйста, не используйте другие короткие теги в вашем коде. Код-Боги очень злятся, когда ты так делаешь ...
Борислав Сабев
6
Я собираюсь добавить это как быстрый комментарий, потому что уже слишком много длинных ответов: <?не только используется в XML для начального <?xml version="1.0" ?>объявления; это общий синтаксис «инструкций по обработке», второй по распространенности пример <?xml-stylesheet ... ?>. <?phpна самом деле может считаться допустимой инструкцией обработки, как может <?=(как это разрешено в 5.4+), но утверждение всего этого <?также создает ненужный конфликт между синтаксисами.
IMSoP

Ответы:

374

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

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

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

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

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

Oli
источник
91
Итак, объяснение таково: они плохие, потому что их не поддерживают? Но почему они не поддерживаются? Потому что они не являются частью спецификации? Хорошо, но почему они не являются частью спецификации? Я немного разочарован этим ответом.
Йозеф Сабл
61
Я здесь не для того, чтобы обсуждать «большие вопросы», например, почему мы здесь, как все это началось и т. Д. Поддержка шорттагов не гарантируется на общих серверах, и она полностью удаляется в следующей основной версии. Это все, что вам нужно знать.
Оли
39
Обязательный PHP - это шаблонизатор. : P
Синтаксическая ошибка
49
Короткие метки не выводятся из употребления. Только короткие ярлыки в стиле ASP.
Брайан Лейси
46
В (очень близком) будущем PHP 5.4 использование <? = Будет отделено от того, включены или отключены short_open_tags. <? = не прекращается, скорее наоборот, теперь считается фундаментальной частью языка.
Г-н Гривер
176

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

Паоло Бергантино
источник
41
@ B Seven Если вы попытаетесь избежать любой теоретической проблемы, которая может возникнуть, ваш код почти наверняка будет неэффективным и ошибочным. Пока группа PHP не согласится постепенно сокращать теги [не теги ASP], беспокойство по поводу укуса будет намного меньше, а потенциальное решение будет намного проще, чем другие вещи, которые вы можете потратить на «исправление» своего времени.
SamGoody
18
если вас это укусит, перейдите на лучший хостинг
Lie Ryan
4
Я не совсем согласен с тем, чтобы не использовать что-то, потому что это может не поддерживаться. Не следует ли нам использовать какие-либо другие функции, которые могут не поддерживаться на сервере? MYSQL против MYSQLI? Вы будете тратить свое время понемногу, снова и снова писать длинные теги, чтобы избежать малейшего шанса потратить немного времени на переход к лучшему хосту.
Дин Или
2
@BSeven, Вы имеете в виду, что вы не используете какие-либо расширения PHP, за исключением поставляемых по умолчанию?
Pacerier
143

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

Таким образом, сам ярлык echo ( <?=) теперь безопасен для использования.

dukeofgaming
источник
19
Я бы сказал, что это единственный «короткий ярлык». <?phpможет быть использован в начале всех файлов классов, а затем у вас есть <?=для ваших представлений. обоюдный выигрыш.
Xeoncross
6
So the echo shortcut itself (<?=) is safe to use... до тех пор, пока вам удобно, требуется PHP 5.4. Широко распространенные приложения PHP (такие как wordpress) не могут позволить себе роскошь требовать 5.4, и даже продолжают предлагать поддержку PHP 4 вплоть до 2011 года - целых 7 лет после выхода PHP 5. Если вы находитесь в таком месте, как Facebook, где все установки вашего программного обеспечения напрямую управляются самой компанией, то требовать поддержки 5.4 намного проще, чем если вы работаете над проектом, подобным WordPress.
Фрэнк Фармер
@dukeofgaming, Ух ты хороший улов, не знал, что их версии SVN доступны в Интернете.
Pacerier
82

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

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

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

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

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

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

Брайан Лейси
источник
6
Если по какой-то причине у вас был настроен apache для передачи XML-файлов в mod_php, то <? Xml - это головная боль с короткими тегами. Но это, очевидно, странная установка.
Франк Фармер
3
Шаблонный язык , который не может быть встроен без обходных путей в некоторых типах выходных документов является большим провалом. Единственная причина, по которой у меня не должно быть шаблона XML с кодом PHP и короткими тегами, заключается в том, что он не работает, а не потому, что он не имеет смысла.
Винко Врсалович
8
Нет ничего страшного в том, чтобы воспользоваться преимуществами PHP как быстрого и удобного языка шаблонов. Как я уже говорил, необходимо взвесить преимущества и недостатки и написать код таким образом, чтобы он соответствовал выбранному вами подходу. Не категорически отвергайте действительный подход только потому, что он не работает в одном конкретном сценарии (который легко можно обойти).
Брайан Лейси
5
Я категорически не отвергаю какой-либо действительный подход (см. Мой ответ на вопрос.) Вы тот, кто категорически отвергает PHP в XML, я цитирую: «Вы все равно не должны смешивать PHP и XML». Кроме того, большой ошибкой, на которую я ссылался, было решение использовать <?в качестве короткого тега, потому что это приводит к уродливым обходным путям в XML. Тем не менее, я согласен, что это вопрос взвешивания выгод и недостатков, и что, если вы знаете, что делаете, вы, безусловно, можете это сделать. Но это не делает <?хороший выбор.
Винко Врсалович
3
Я немного опоздал на вечеринку, но мне очень нравится этот ответ, и он отражает мой опыт с ситуацией. Хотя у нас есть некоторые разногласия по этому вопросу в нашем офисе, я могу сказать, что из-за почти ежедневной работы в php в течение многих лет я никогда не сталкивался с этой проблемой. Когда PHP используется для генерации XML, он, по моему опыту, всегда был в контексте высокодинамичного контента, который никогда напрямую не шаблонизировался через PHP, поэтому проблема никогда не возникает.
Redreinard
33

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

ОБНОВИТЬ

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

<?php and <?php echo

над

<? and <?=

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

Джейк МакГроу
источник
8
Я фрилансер, и весь мой код переходит на виртуальный хостинг, так что никакого контроля вообще! :)
MDCore
12
Если у вас достаточно клиентов, перейдите на свой собственный coloc, общий хостинг небезопасен и нестабилен.
Джейк Макгроу
2
Короткие теги, которые Zend возвращал, очевидно, не уловили, так как Zend использует длинную версию: framework.zend.com/manual/en/zend.view.scripts.html
Джерри
3
@ Джерри Я также недавно читал об этом, см. Последний комментарий к этой теме: Обновите .htaccess, чтобы включить короткие открытые теги
MrWhite
2
Вы должны действительно исправить грамматику в первом предложении после ОБНОВЛЕНИЯ, которая не имеет смысла в ее текущей форме.
Redreinard
22

Потому что путаница может генерироваться с декларациями XML. Хотя многие с вами согласны .

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

Винко Врсалович
источник
Не вызовет ли декларация XML путаницы, если short_tags включен?
MDCore
Таким образом, вместо непосредственного вывода объявления XML, у вас есть PHP-эхо. Это не очень хорошее опровержение.
Moo
Это не опровержение чего-либо. Это единственная действительная причина, которая, в свою очередь, является причиной по другой причине «хостер выключает ее», конечно, вы можете использовать ее, если вы знаете, что делаете, как всегда.
Винко Врсалович
1
@macek: я знаю об этом. Это был только первый пример, о котором я подумал. Еще, что если вы вставите PHP в файл XML? Вы не можете сделать это напрямую. И не говорите мне решение этой проблемы, я знаю о них. Дело в том, что у PHP есть много способов для анализа XML-файла. Вы можете, вероятно, отклонить их все с помощью обходных путей ( <?='<?xml') или сказать «вы не должны этого делать», но это не делает факт того, что это может произойти, исчезает.
Винко Врсалович
1
Как короткие метки боль, если они не работают? это очень легко сделать большую часть и заменить <?=на <? echo . многие текстовые редакторы могут легко справиться с этим одновременно с тысячами файлов.
Ямико
20

Следующее - замечательная схема потока того же самого:

дерево принятия решений об использовании <? =

Источник: похожий вопрос о разработке программного обеспечения стека обмена

Sumoanand
источник
2
Здесь описывается, следует ли использовать короткий эхо-тег, не совпадающий с <?короткими тегами, упомянутыми в вопросе (хотя он использовал те же настройки конфигурации до 5.4)
Alok
На самом деле это должен быть ответ, который может понять каждый, хотя обстоятельства на самом деле не объясняются, почему вы не хотите использовать короткие теги во многих случаях (например, не можете изменить файл php.ini в системе общего хостинга)
Бьорн К
14

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

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

а также

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

а также

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

Оливер Чарльзуорт
источник
14

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

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

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

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

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

ConroyP
источник
2
Короткие теги включены в 95% веб-серверов.
Паоло Бергантино
19
Я не покупаю аргумент "читабельности". Если вы используете PHP в качестве языка шаблонов, <?= $var ?>его гораздо удобнее читать<?php echo $var ?>
Фрэнк Фармер
2
@ Пауло, возможно, это изменилось с 2008 года, но в экземплярах EC2 Ubuntu и Fedora с версиями PHP yum install и apt-get по умолчанию отключены короткие теги
Дуг Молиньюс
2
используйте полные теги, и вы получите 100% :)
Elvis Ciotti
1
@FrankFarmer, я думаю, что он сравнивает тот без эха. <?против <?php.
Pacerier
11

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

brunoais
источник
5

Я прочитал эту страницу после поиска информации по этой теме и чувствую, что одна из главных проблем не была упомянута: лень и последовательность. «Реальными» тегами для 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+ варианта?

Даниэль Росс
источник
4

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

Greg
источник
4

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

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

patricksweeney
источник
3

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

{$myString|escape}

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

<?= htmlspecialchars($myString) ?> 
Адриан Джадд
источник
10
Для большинства программистов PHP второй вариант имеет больше смысла, чем первый, просто потому, что мы знакомы с реальной функцией PHP, в то время как первый вариант - это псевдо-шаблонный код, который мы должны изучить поверх PHP. PHP уже является языком шаблонов, добавляя к нему еще один язык шаблонов, такой как Smarty - избыточный IMO.
Жучок Магнит
3
Twig - это шаблонизатор с html-экранированием, включенным по умолчанию. Twig.sensiolabs.org
mateusza
3

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

Быстрее набрать

MDCore сказал:

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

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

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

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

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

Легче читать

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

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

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

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

Вывод

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

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

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

Джеймс
источник
Это не имеет ничего общего с набором текста. Это короче и, следовательно, может быть легче читать . Человек, привыкший читать, <?=будет читать <?=легче, чем человек, привыкший <?php echoчитать <?php echo.
Pacerier
@Pacerier Shorter не просто = легче читать. Мы все разные. Что вы имеете в виду, что легче читать вас . Как я добавил в своем ответе, я привык <?phpвидеть, что во всем коде мне много раз знакомо больше, чем <?=- знакомство делает вещи проще - хотя не обязательно лучше.
Джеймс
Нет, я не сравниваю вас и меня, я говорю, что человек, привыкший читать, <?=будет читать <?=лучше, чем человек, привыкший <?php echoчитать <?php echo. Это означает, что если у нас есть две идентичные копии человека X, и изменять их только в том аспекте, при котором одна используется для чтения <?=, а другая - для чтения <?php echo, первая копия может достичь значения читабельности xпри чтении с использованием его желаемого синтаксиса, в то время как вторая копия может достичь значения читабельностиy при чтении желаемого синтаксиса, где x >= y.
Pacerier
Нет, ты упускаешь суть. Я имею в виду потенциал системы, которая не имеет никакого отношения к какому-либо конкретному человеку. Вы можете сказать, что люди, привыкшие печатать на клавиатуре qwerty, будут печатать быстрее с qwerty, тогда как люди, привыкшие печатать на dvorak, будут печатать быстрее на dvorak, но факт не меняет того, что две системы имеют разный потенциал.
Pacerier
3

Давайте смотреть правде в глаза. PHP безобразно безобразен без коротких тегов.

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

php_flag short_open_tag on
Jimmer
источник
3
Ложь. Иногда сервер запрещает любые переопределения, сэр.
Альфабраво
17
Верно, но если ваш хост не позволяет переопределить с помощью htaccess, вам действительно нужен новый хост! :)
Брайан Лейси
1
не работает в интерфейсе командной строки, и php_flag не поддерживается все время
Elvis Ciotti
3

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

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

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

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

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

stereoscott
источник
2

Я думал, что стоит упомянуть, что в 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

Manngo
источник
1
Если я не ошибаюсь, ваш первый пункт неверен. В документе сказано, что ASP-теги, а не короткие теги PHP, ушли с PHP 7.0.0.
реформирован
@reformed Вы абсолютно правы. Я отредактирую свой ответ. Спасибо
Manngo
1

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

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

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

Корнель
источник
7
Если вы обнаружите, что набираете «<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 раз в день, возможно, вы захотите создать функцию ярлыка с именем« h », как у Rails ..» < ? = h ($ text)?> "гораздо удобнее читать при сканировании шаблона.
Александр Малфей,
1
Это действительно лучше, но с механизмом шаблонов это может быть просто $ {text} или что-то подобное (и вам не нужно добавлять h ())
Корнел
7
Сам PHP является движком шаблонов. Когда вы перестаете использовать короткие теги, это становится плохим движком шаблонов, так как становится слишком многословным.
Йозеф Сабл
1
@ Александр Малфей, это хороший совет. Но <? = Не нужен. Вы можете просто заставить функцию выводить строку вместо return, тогда вы напишите <? Php h ('hello')?> Разве мы уже не делаем это, когда мы де i18n? <? php _e ('')?> не так уж и плохо.
ВладФр
1

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

Короткие метки будут выделены как светло-красные, а более длинные выделены темнее!

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

M50Scripts
источник
1

Преобразовать <?(без завершающего пробела) в <?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'
Фатих Акгун
источник
1

Короткие метки всегда доступны в 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>
GaziAnis
источник
1

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

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

или короткие эхо-метки

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

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

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

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

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

Blackbam
источник
1

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

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

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

GaziAnis
источник
Это не отвечает на вопрос.
RalfFriedl
-5

Нет, в PHP 6 они постепенно сокращаются, поэтому, если вы цените долговечность кода, просто не используйте их или <% ... %>теги.

coderGeek
источник
4
Я видел другие посты в блогах, в которых говорится, что они не будут устаревшими, только короткие теги в стиле ASP.
MDCore
22
Похоже, этот ответ неверен, согласно этой ссылке со встречи разработчиков PHP: php.net/~derick/…
Чарльз,
7
ПОЧЕМУ они такие плохие, почему? Все настолько уверены в себе, что они баааааад, но никто не говорит почему.
Йозеф Сабл
6
ЛОЖНЫЙ. Они постепенно сокращают теги <%%>, как это и должно быть. Они не служат никакой цели, кроме как запутать. <? ?> теги не будут затронуты; но, конечно, они по-прежнему настраиваются для каждого сервера, и вы всегда должны знать о требованиях вашей целевой платформы.
Брайан Лейси
6
Эта информация представляется неверной и вводящей в заблуждение, и она должна быть исправлена ​​автором.
текс