Почему бы опустить закрывающий тег?

Question

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

Современные версии PHP устанавливают флаг output_buffering в php.ini. Если буферизация вывода включена, вы можете установить заголовки HTTP и файлы cookie после вывода HTML, поскольку возвращенный код не отправляется в браузер немедленно.

Каждая книга хорошей практики и вики начинаются с этого «правила», но никто не приводит веских причин. Есть ли еще одна веская причина пропустить конечный тег PHP?

Answer 1

Плюсы

• Было бы логично закрыть любой открытый тег , как с другими языками. Не только метки X (HT) ML, но и фигурные скобки, скобки ...
• Менее запутанно для начинающих .

Против

• Предотвращает головную боль благодаря непреднамеренному добавлению пробелов после закрывающего тега, поскольку он нарушает поведение функции header () ... Известно также, что некоторые редакторы или FTP-клиенты / серверы изменяются автоматически конец файлов (по крайней мере, это их конфигурация по умолчанию)
• Руководство по PHP говорит, что закрывающий тег необязателен , а Zend даже запрещает его .

Заключение

Я бы сказал, что аргументы в пользу пропуска тега выглядят сильнее (помогает избежать большой головной боли при header () + это "рекомендация" PHP / Zend). Я признаю, что это не самое «красивое» решение, которое я когда-либо видел с точки зрения согласованности синтаксиса, но что может быть лучше?

Answer 2

Поскольку мой вопрос был помечен как дубликат этого вопроса, я думаю, что можно писать, почему NOT опускающий закрывающий тег ?> может быть по некоторым причинам желательным.

• С полным синтаксисом инструкций по обработке (<?php ... ?>) исходный код PHP является действительным документом SGML, который может быть проанализирован и обработан без проблем с синтаксическим анализатором SGML.С дополнительными ограничениями это может быть также действительный XML / XHTML.

Ничто не мешает вам писать действительный код XML / HTML / SGML. PHP документация знает об этом.Выдержка:

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

Конечно, синтаксис PHP не является строгим SGML / XML / HTML, и вы создаете документ, который не является SGML / XML / HTML, точно так же, как вы можете превратить HTML в XHTML, чтобы он соответствовал XML или нет.

• В какой-то момент вы можете захотеть объединить источники.Это будет не так просто, как просто сделать cat source1.php source2.php, если у вас есть несоответствие, введенное путем пропуска закрывающих тегов ?>.

• Без ?> Труднее сказать, если документ оставлен вРежим выхода PHP или режим игнорирования PHP (тег PI <?php может быть открыт или нет).Жизнь становится проще, если вы постоянно оставляете свои документы в режиме игнорирования PHP.Это похоже на работу с хорошо отформатированными документами HTML по сравнению с документами с закрытыми, плохо вложенными тегами и т. Д.

• Похоже, что в некоторых редакторах, таких как Dreamweaver, могут быть проблемы с открытым PI [1] .

Answer 3

Существует 2 варианта использования php-кода:

1. PHP-код, такой как определение класса или определение функции
2. Использование PHP в качестве языка шаблонов (т.е. в представлениях)

в случае 1. закрывающий тег совершенно бесполезен, также я хотел бы видеть только 1 (один) открытый тег php и NO (нулевой) закрывающий тег в таком случае.Это хорошая практика, поскольку она делает код чистым и отделяет логику от представления.Для случая представления (2.) некоторые обнаружили, что естественно закрыть все теги (даже обработанные PHP), что приводит к путанице, поскольку на самом деле PHP имеет два отдельных варианта использования, которые не должны смешиваться: логика / исчислениеи презентация

Answer 4

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

И, возможно, именно поэтому большинство ответов вернулось к личному стилю и синтаксису.