Tag de fechamento (?>) Em arquivos PHP?


17

Algumas pessoas juram que fecham seus arquivos PHP ?>, outras dizem que é mais otimizado deixá-lo de fora.

Sei que não é essencial tê-lo lá, só estou me perguntando quais são os prós e os contras de fazer isso e qual é a melhor prática.



Algumas pessoas estão assumindo que a frase "mais otimizado" pretendia significar "correrá mais rápido". O falante (cuja língua materna pode não ser o inglês) pode ter pretendido algo mais como "mais ideal" ou "uma prática melhor".
Scott C Wilson

Respostas:


27

Não é tanto uma questão de desempenho - analisar a trilha ?>é trivial e não fará nenhuma diferença perceptível, a menos que você inclua um milhão de arquivos por segundo.

IIRC, o php.net recomenda NÃO adicionar o ?>, e os motivos são mais ou menos assim:

  • é desnecessário
  • é fácil adicionar acidentalmente espaços em branco significativos após o ?>, que serão gerados no cliente, o que por sua vez pode levar a erros obscuros de 'cabeçalhos já enviados' (isso acontece quando um arquivo incluído contém espaços em branco e você tenta definir um cabeçalho após incluindo esse arquivo)

Com base nas respostas aqui (principalmente em relação ao espaço em branco indesejado que causa erros de "cabeçalhos já enviados"), mudei meu hábito de incluir religiosamente um?> No final de um arquivo PHP. Notei que quando criei um novo arquivo com o PHPStorm, o modelo inseriu um <? Php sem a marca de fechamento?> E pensei que era apenas uma codificação desleixada. Agora eu sei melhor.
precisa saber é o seguinte

Esse motivo preciso - "cabeçalhos já enviados" - foi o motivo pelo qual foi rigorosamente proibido pelo meu empregador (um grande portal da web). Uma coisa é esquecê-la no final de um arquivo que você acabou de escrever. Outra é que, se você editar uma entrada da biblioteca com 3 itens, o seu editor de texto inserirá o espaço em branco sem que você saiba e, de repente, um pedaço do portal executado por caras a 2 edifícios de distância deixará de funcionar. A árvore de inclusões costuma ter mais de 100 arquivos, encontrar o bug se torna um exercício de paciência. Espere uma visita de "profunda gratidão" semanas depois, quando o bug for encontrado e rastreado até você.
SF.

1
O PHP que envia espaço em branco após a tag de fechamento é mais um exemplo de decisões ruins de linguagem.
user949300

12

Não, eles estão errados.

?>é opcional no PHP no final de um arquivo. E você encontrará uma boa razão para isso. O mais importante é que um espaço vazio no final de um arquivo não impeça o envio de cabeçalhos. Este é um bug difícil de detectar, pois você pode encontrá-lo em qualquer arquivo em qualquer lugar.

A maneira usual de fazer isso é colocar uma marca de fechamento quando o PHP é misturado com HTML e não colocá-la para arquivos PHP puros. É até um padrão de codificação do framework ZEND e muitos outros.

Otimizado significa que o código é executado mais rapidamente. É fácil provar que eles estão errados. Perfile o código e descubra que eles estão lhe dizendo besteira.


4

Eu acho que é recomendado para iniciantes para evitar adicioná-lo para que eles não façam com que caracteres extras de nova linha sejam enviados acidentalmente. Como não é essencial tê-lo como você mencionou, acho que o raciocínio geral é que é melhor deixá-lo para evitar erros.

Eu não acho que haja qualquer "otimização" envolvida.

Eu gostaria de indicá-lo aqui: /programming/4410704/php-closing-tag e aqui: /programming/3219383/why-do-some-scripts-omit-the -closing-php-tag


1
novatos ou não ... simplesmente não há razão (exceto para casos de TOC) para tê-los #
619

@Mchl gostaria de salientar que as razões para sair fora são bastante trivial e no final ele se resume a preferência do programador e não é realmente um problema OCD ...
Kenneth

1
Eu me encolho sempre que vejo ?>arquivos contendo PHP puro.
Caffeinated Aviator

@ Kenneth: Se eles são triviais - eu não consigo vê-los. A parte do TOC era para ser uma piada.
Mchl
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.