Каковы аргументы в пользу закрытия тегов PHP для файлов только PHP?

Question

Стандарт кодирования Zend Framework упоминает следующее:

Для файлов, которые содержат только код PHP, закрывающий тег ("?>") Никогда не разрешается. Это не требуется PHP, и его пропуск предотвращает случайное внедрение конечного пробела в ответ.

• Стандарт кодирования Zend Framework: форматирование файла

Однако я помню, что слышал о проблеме (с инструментами или, может быть, включая?), Где файлы должны иметь закрывающий тег.

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

Answer 1

Удаление закрывающих тегов, когда это возможно, вероятно, является наилучшей практикой. Причина этого в том, что если у вас есть какой-либо символ (даже пробел) за пределами?> В php-файле, он может прекратить работу таких вещей, как заголовки, чтобы перестал работать, если символ будет отправлен в браузер до того, как будет установлен заголовок.

Answer 2

Если вы используете закрывающие теги PHP, вы можете легко найти файлы, которые были случайно обрезаны (например, не были загружены полностью).
Однако такую ​​проблему следует решить, сделав файловую систему и передачу надежной, а не добавляя теги «canary» PHP:)

Другая возможная причина - это требование стандартов кодирования PEAR. Они требуют этого, потому что они этого требуют, и вы не можете ставить под сомнение стандарты кодирования PEAR.

Answer 3

Вы можете рассматривать открывающий тег php для файлов только для php, как своего рода строку shebang (например, #! / Bin / bash), поэтому вам не нужен закрывающий тег.

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

Answer 4

Я всегда пишу закрывающий тег для php-файлов и целенаправленно не следую за ним пробелами или eol.

Стандарт подразумевает, что если закрывающий тег пропущен, он будет предоставлен неявно. Но это не освобождает разработчика от написания правильного HTML / XML.

И могут быть случаи, когда два файла объединяются вне обработки html / php, а отсутствующий тег может вызвать крайнюю печаль.

Answer 5

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

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

Answer 6

Проверка ошибок кодирования не работает при объединении нескольких файлов. Я использую следующую команду оболочки для проверки ошибок.

find . -name '*.php' | xargs cat | php -l

Конечно, следующая команда все еще работает (и отображает имя поврежденного файла)

find . -name '*.php' | while read filename; do php -l $filename | grep -v 'No syntax errors '; done

Но этот намного медленнее.

Answer 7

Я всегда использую закрывающие теги, без них это выглядит не очень хорошо. Это также недопустимая инструкция обработки xml без них (не то, чтобы вы заботились, если в файле есть только php)

Answer 8

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

Поскольку он всегда работал для Drupal (и я знал, что, читая руководство, это было необязательно), я однажды создал файл конфигурации (который содержал только код PHP) без закрывающего тега. По некоторым причинам это не работало, пока (по настоянию коллеги) я не добавил закрывающий тег. В то время мы не пытались выяснить причину.

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

Answer 9

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

В ответ на @CesarB, если вы не можете привести конкретный, воспроизводимый пример, все, что вы делаете, это распространяете FUD. В руководстве по PHP очень ясно, что закрывающий тег необязателен.

Answer 10

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

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