Каковы аргументы в пользу закрытия тегов PHP только для файлов PHP?
стандарт кодирования Zend Framework упоминает следующее:
Для файлов, содержащих только PHP-код, закрывающий тег ("?>") не допускается. Это не требуется PHP, и его опущение предотвращает случайное введение конечных пробелов в ответ.Я помню о проблеме (с оснасткой или может?) где файлы необходимо иметь закрывающий тег.
кто-нибудь знает о каких-либо проблемах (кроме проблемы с разработчиком симметрии), где вам нужно будет иметь закрывающие теги или они вообще плохая идея?
10 ответов
удаление закрывающих тегов, когда вы можете, вероятно, лучшая практика. Причина этого в том, что если у вас есть любой символ (даже пробел), за пределами ?> в php-файле он может остановить такие вещи, как заголовки, чтобы перестать работать, если символ отправляется в браузер до того, как заголовок будет установлен.
Если вы используете закрывающие теги PHP, вы можете легко найти файлы, которые были случайно усечены (например, не были загружены полностью).
Однако такая проблема должна быть исправлена, сделав файловую систему и передачи надежными, а не добавляя PHP "канарейки" теги :)
еще одна возможная причина заключается в том, что стандарты кодирования PEAR требуют этого. Они требуют этого, потому что они требуют этого, и вы не можете подвергать сомнению стандарты кодирования груши.
вы можете рассмотреть открывающий тег php для файлов только php, как своего рода строку shebang (например,#!/bin / bash), таким образом, вам не нужен закрывающий тег.
мы также следуем стандарту ZF, без закрывающего тега для файлов только php. Но я никогда не слышал о каком-либо инструменте, который не мог бы разобрать файл из-за отсутствующего закрывающего тега, и я еще не сталкивался с проблемами из-за того, что не использовал его.
Я всегда пишу закрывающий тег для файлов php и целенаправленно не следую за ним с пробелами или eol.
стандарт подразумевает, что если закрывающий тег опущен, он будет неявно предоставлен. Но это не освобождает разработчика от написания правильного html/xml.
и могут быть случаи, когда два файла объединяются вне обработки html/php, а отсутствующий тег вызовет крайнее горе.
Я всегда помещаю их, потому что я рассматриваю их как причудливую закрывающую скобку - как когда я пишу условные обозначения и петли, которые я помещаю в пару открытых/закрытых скобок перед написанием кода, я делаю с файлами PHP.
независимо от того," правильно "это или нет, я часто превращаю" чистые "PHP-файлы в" не чистые", и закрывающий тег чрезвычайно полезен.
Я всегда использую закрывающие теги, это просто не выглядит хорошо без них. Это также не действительная инструкция по обработке xml без них (не то, что вам все равно, если единственное, что в файле php)
мы используем Drupal, который всегда отсутствует закрывающий тег, и никогда не было никаких проблем из-за этого.
поскольку он всегда работал для Drupal (и я знал из чтения руководства, что это необязательно), я однажды создал файл конфигурации (который содержал только PHP-код) без закрывающего тега. По какой-то причине это не сработало, пока (по настоянию коллеги) я не добавил закрывающий тег. В то время мы не пытались выяснить причину.
Я всегда использовал закрытия тег в коде я пишу; он выглядит более симметричным, концептуально "закрывает" открывающий тег, и я всегда стараюсь не оставлять лишних пробелов после закрывающего тега.
проверка на ошибки в коде не работает, когда concating несколько файлов. Я использую следующую команду shell для проверки ошибок.
find . -name '*.php' | xargs cat | php -l
конечно, следующая команда все еще работает (и отображает имя файла поврежденного файла)
find . -name '*.php' | while read filename; do php -l $filename | grep -v 'No syntax errors '; done
но этот намного медленнее.
наш офис работает с приложениями электронного обучения, встроенными во Flash, и мы обнаружили, что если закрывающий тег опущен из сценариев на стороне сервера, то он нарушает наш механизм связи с приложениями e-learnng.
одно предостережение к этому было бы то, что наш процесс debuggng сначала не попробовал его в упрощенной среде, чтобы убедиться, что это не комбинация отсутствующих закрывающих тегов и некоторых ошибочных выходных данных, поступающих из другого скрипта....
в ответ на @gabriel1836 закрывающие теги на стороне сервера не имеют значения, когда дело доходит до Flash-приложений; что актуально, так это полезная нагрузка, возвращаемая сервером в ответ на запрос удаленного взаимодействия Flash-приложением. Исключение закрывающего тега в файлах только PHP повлияет на это только в том случае, если ложные выходные данные не будут возвращены до отправки заголовков в приложение Flash.
в ответ на @CesarB, если вы не можете дать конкретный, воспроизводимый пример, все ты распространяешь ФАД. Руководство PHP очень ясно, что закрывающий тег является необязательным.