Por que alguém omitiria a marca fechada?

Eu continuo lendo que é uma prática ruim usar a tag close PHP ?>no final do arquivo. O problema do cabeçalho parece irrelevante no contexto a seguir (e este é o único bom argumento até agora):

Versões modernas do PHP definem o sinalizador output_buffering no php.ini Se o buffer de saída estiver ativado, você poderá definir cabeçalhos e cookies HTTP após a saída do HTML, pois o código retornado não será enviado ao navegador imediatamente.

Todo livro de boas práticas e wiki começa com essa 'regra', mas ninguém oferece boas razões. Existe outra boa razão para pular a tag PHP final?

O envio de cabeçalhos antes do curso normal pode ter consequências de longo alcance. Abaixo estão apenas alguns deles que vieram à minha mente no momento:

1. Embora as versões atuais do PHP possam ter buffer de saída ativado, os servidores de produção reais nos quais você estará implantando seu código são muito mais importantes do que qualquer máquina de desenvolvimento ou teste. E eles nem sempre tendem a seguir as últimas tendências do PHP imediatamente.

2. Você pode ter dores de cabeça devido à perda inexplicável de funcionalidades . Digamos que você esteja implementando algum tipo de gateway de pagamento e redirecione o usuário para um URL específico após a confirmação bem-sucedida pelo processador de pagamento. Se algum tipo de erro de PHP, mesmo um aviso ou um excesso de final de linha ocorrer, o pagamento poderá não ser processado e o usuário ainda poderá parecer não faturado. Essa também é uma das razões pelas quais o redirecionamento desnecessário é ruim e, se for necessário usá-lo, ele deve ser usado com cautela.

3. Você pode receber erros do tipo "Carregamento da página cancelado" no Internet Explorer, mesmo nas versões mais recentes. Isso ocorre porque uma resposta AJAX / json include contém algo que não deve conter, devido ao excesso de terminações de linha em alguns arquivos PHP, assim como eu encontrei alguns dias atrás.

4. Se você tiver alguns downloads de arquivos no seu aplicativo, eles também podem ser danificados por causa disso. E você pode não perceber, mesmo depois de anos, já que o hábito de quebra específico de um download depende do servidor, do navegador, do tipo e do conteúdo do arquivo (e possivelmente de outros fatores com os quais não quero aborrecer) .

5. Finalmente, muitas estruturas PHP, incluindo Symfony , Zend e Laravel (não há menção disso nas diretrizes de codificação, mas seguem o exemplo) e o padrão PSR-2 (item 2.2) exige a omissão da tag de fechamento. O próprio manual do PHP ( 1 , 2 ), Wordpress , Drupal e muitos outros softwares PHP, eu acho, aconselham a fazê-lo. Se você simplesmente seguir o padrão (e configurar o PHP-CS-Fixer para o seu código), poderá esquecer o problema. Caso contrário, você sempre precisará manter o problema em sua mente.

Bônus: algumas dicas (atualmente atualmente uma) relacionadas a esses 2 personagens:

1. Mesmo algumas bibliotecas conhecidas podem conter excesso de terminações de linha depois ?>. Um exemplo é o Smarty, mesmo as versões mais recentes das ramificações 2. * e 3. * têm isso. Portanto, como sempre, preste atenção ao código de terceiros . Bônus em bônus: uma regex para excluir finais PHP desnecessários: substitua (\s*\?>\s*)$por texto vazio em todos os arquivos que contêm código PHP.

O motivo de você deixar de lado a tag de fechamento php ( ?>) é para que o programador não envie acidentalmente caracteres extras de nova linha.

A razão pela qual você não deve deixar de lado a tag de fechamento do php é porque ela causa um desequilíbrio nas tags php e qualquer programador com uma mente decidida se lembra de não adicionar espaço em branco extra.

Então, para sua pergunta:

Existe outra boa razão para pular a tag php final?

Não, não há outro bom motivo para pular as tags php finais.

Terminarei com alguns argumentos para não me incomodar com a tag de fechamento:

1. As pessoas sempre são capazes de cometer erros, por mais inteligentes que sejam. Aderir a uma prática que reduz o número de possíveis erros é (IMHO) uma boa idéia.

2. PHP não é XML. O PHP não precisa seguir os rígidos padrões de XML para ser bem escrito e funcional. Se uma tag de fechamento ausente o incomoda, você pode usar uma tag de fechamento, não é uma regra definida de uma maneira ou de outra.

É uma recomendação de estilo de codificação para iniciantes , bem-intencionada e recomendada pelo manual .

• Evitar, ?>no entanto, resolve apenas uma série de cabeçalhos comuns que já enviaram causas (saída bruta, lista técnica , avisos etc.) e seus problemas de acompanhamento.

• Na verdade, o PHP contém alguma mágica para eliminar quebras de linha únicas após o ?>token de fechamento. Embora isso tenha problemas históricos , deixe os recém-chegados ainda suscetíveis a editores esquisitos e, de maneira inesperada, embaralhando em outros espaços em branco depois ?>.

• Estilisticamente, alguns desenvolvedores preferem visualizar <?phpe ?>como instruções de processamento de tags / XML SGML, implicando a consistência do saldo de um token próximo à direita. (Qual btw, é útil para a classe de conjunto de dependências, inclui substituir o carregamento automático ineficiente de arquivo por arquivo.)

• De maneira um tanto incomum, a abertura <?phpé caracterizada como PHPs shebang (e totalmente viável por binfmt_misc ), validando a redundância de uma tag de fechamento correspondente.

• Há uma discrepância aconselhar óbvia entre guias de sintaxe clássica PHP obrigatoriedade ?>\ne quanto mais queridos recentes (PSR-2) que concordam com omissão.
  (Para constar: o Zend Framework postular um sobre o outro não implica sua superioridade inerente. É um equívoco que os especialistas tenham sido atraídos para o público-alvo de APIs pesadas).

• SCMs e IDEs modernos fornecem soluções integradas, em geral, aliviando o cuidado com as tags de fechamento.

Desencorajar qualquer uso do ?> tag close simplesmente atrasa a explicação do comportamento básico do processamento PHP e da semântica da linguagem para evitar problemas pouco frequentes. Ainda é prático para o desenvolvimento de software colaborativo devido a variações de proficiência nos participantes.

Fechar variações de tag

• A tag de fechamento regular ?> também é conhecida comoT_CLOSE_TAG "token próximo".

• Compreende mais algumas encarnações, devido à nova linha mágica de PHPs :

  ?>\n (Avanço de linha Unix)

  ?>\r (Retorno de carro, MACs clássicos)

  ?>\r\n (CR / LF, no DOS / Win)

  PHP não suporta a quebra de linha combinada Unicode NEL (U + 0085).

  As primeiras versões do PHP tinham compilações do IIRC limitando um pouco o agnosticismo da plataforma (o FI apenas usou > como marcador próximo), que é a provável origem histórica da evitação de marcas próximas.

• Muitas vezes esquecido, mas até o PHP7 removê-los , o <?phptoken de abertura regular pode ser validamente emparelhado com o raramente usado </script>como token de fechamento ímpar .

• A " etiqueta rígida " não é sequer uma - apenas criou esse termo para analogia. Conceitualmente e em termos de uso, __halt_compilerno entanto, deve ser reconhecido como um símbolo próximo.

  __HALT_COMPILER();
  ?>

  Basicamente, o tokenizador descarta qualquer código ou seções HTML simples posteriormente. Em particular, os stubs PHAR fazem uso disso ou de sua combinação redundante com ?>o descrito.

• Da mesma forma, um nuloreturn; raramente substitui os scripts de inclusão, tornando qualquer um ?>com espaço em branco à direita ineficaz.

• Depois, existem todos os tipos de variações de tags fechadas suaves / falsas ; menos conhecido e raramente usado, mas geralmente por tokens comentados :

  • Espaçamento simples // ? >para evitar a detecção pelo tokenizador PHPs.

  • Ou substitutos Unicode sofisticados // ﹖﹥(MARCA DE PERGUNTA PEQUENA U + FE56, SUPORTE DE ÂNGULO PEQUENO U + FE65) que um regexp pode entender.

  Ambos não significam nada para o PHP , mas podem ter usos práticos para kits de ferramentas externos inconscientes ou semi-conscientes do PHP. catOs scripts novamente associados vêm à mente, com as // ? > <?phpconcatenações resultantes que mantêm em linha o arquivo anterior.

Portanto, existem alternativas dependentes do contexto, mas práticas, para uma omissão imprescindível.

A babá manual de ?>tags fechadas não é muito contemporânea de qualquer maneira. Sempre houve ferramentas de automação para isso (mesmo que apenas sed / awk ou regex-oneliners). Em particular:

phptags tag tidier

https://fossil.include-once.org/phptags/

Que geralmente pode ser usado para --unclosephp tags de código de terceiros ou apenas para corrigir qualquer (e todos) problemas de espaço em branco / BOM:

• phptags --warn --whitespace *.php

Ele também lida com a --longconversão de tags etc. para compatibilidade de tempo de execução / configuração.

Não é uma etiqueta ...

Mas se você o tiver, corre o risco de ter espaço em branco depois dele.

Se você o usar como inclusão na parte superior de um documento, poderá inserir espaço em branco (ou seja, conteúdo) antes de tentar enviar cabeçalhos HTTP ... o que não é permitido.

É bastante útil não permitir o fechamento ?>.

O arquivo permanece válido para o PHP (não é um erro de sintaxe) e, como @David Dorward disse, permite evitar espaços em branco / linhas de quebra (qualquer coisa que possa enviar um cabeçalho para o navegador) após o ?> .

Por exemplo,

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10);
    imagepng ( $img);
?>
[space here]
[break line here]

não será válido.

Mas

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10 );
    imagepng ( $img );

vai.

Pela primeira vez, você deve ter preguiça de estar seguro .

De acordo com os documentos , é preferível omitir a tag de fechamento se estiver no final do arquivo pelo seguinte motivo:

Se um arquivo é puro código PHP, é preferível omitir a tag de fechamento do PHP no final do arquivo. Isso evita que espaços em branco acidentais ou novas linhas sejam adicionadas após a tag de fechamento do PHP, o que pode causar efeitos indesejados, porque o PHP iniciará o buffer de saída quando não houver intenção do programador de enviar qualquer saída nesse ponto do script.

Manual do PHP> Referência da linguagem> Sintaxe básica> Tags PHP

Bem, eu sei o motivo, mas não posso mostrar:

Para arquivos que contêm apenas código PHP, a tag de fechamento ( ?>) nunca é permitida. Não é requerido pelo PHP, e sua omissão impede a injeção acidental de espaço em branco à direita na resposta.

Fonte: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

Bem, existem duas maneiras de ver isso.

1. O código PHP nada mais é do que um conjunto de instruções de processamento XML e, portanto, qualquer arquivo com uma .phpextensão nada mais é do que um arquivo XML que, por acaso, é analisado pelo código PHP.
2. Por acaso, o PHP compartilha o formato de instruções de processamento XML para suas tags de abertura e fechamento. Com base nisso, arquivos com .phpextensões PODEM ser arquivos XML válidos, mas eles não precisam ser.

Se você acredita na primeira rota, todos os arquivos PHP exigem o fechamento de tags finais. Omiti-los criará um arquivo XML inválido. Por outro lado, sem ter uma <?xml version="1.0" charset="latin-1" ?>declaração de abertura , você não terá um arquivo XML válido de qualquer maneira ... Portanto, não é um problema importante ...

Se você acredita na segunda rota, isso abre a porta para dois tipos de .phparquivos:

• Arquivos que contêm apenas código (arquivos de biblioteca, por exemplo)
• Arquivos que contêm XML nativo e também código (arquivos de modelo, por exemplo)

Com base nisso, os arquivos somente de código podem terminar sem uma ?>marca de fechamento . Mas os arquivos de código XML não podem terminar sem um fechamento, ?>pois isso invalidaria o XML.

Mas eu sei o que você está pensando. Você está pensando no que isso importa, nunca processará diretamente um arquivo PHP, então quem se importa se é XML válido. Bem, importa se você está criando um modelo. Se for XML / HTML válido, um navegador normal simplesmente não exibirá o código PHP (é tratado como um comentário). Assim, você pode simular o modelo sem precisar executar o código PHP dentro de ...

Não estou dizendo que isso é importante. É apenas uma visão que eu não vejo expressa com muita frequência, então qual o melhor lugar para compartilhá-lo ...

Pessoalmente, não fecho tags nos arquivos da biblioteca, mas nos arquivos de modelo ... Eu acho que é uma preferência pessoal (e orientação de codificação) baseada mais do que qualquer coisa difícil ...

Além de tudo o que já foi dito, vou apresentar outro motivo que foi uma grande dor para a depuração.

O Apache 2.4.6 com PHP 5.4 realmente falha de segmentação em nossas máquinas de produção quando há espaço vazio atrás da phptag de fechamento . Eu só perdi horas até finalmente estreitar o bug com strace .

Aqui está o erro que o Apache lança:

[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)

"Existe outra boa razão (além do problema do cabeçalho) para pular a tag php final?"

Você não deseja gerar inadvertidamente caracteres de espaço em branco estranhos ao gerar saída binária, dados CSV ou outra saída não HTML.

Prós

• Seria lógico fechar qualquer tag aberta , como em outros idiomas. Não apenas tags X (HT) ML, mas também chaves, suportes ...
• Menos confuso para iniciantes .

Contras

• Evita dores de cabeça ao adicionar espaços em branco inadvertidamente após a tag de fechamento, porque interrompe o comportamento da função header () ... Alguns  editores ou clientes / servidores FTP também são conhecidos por alterar automaticamente o final dos arquivos (pelo menos, é a configuração padrão)
• O manual do PHP diz que a tag de fechamento é opcional e o Zend até a proíbe .

Conclusão

Eu diria que os argumentos a favor da omissão da tag parecem mais fortes (ajuda a evitar grandes dores de cabeça com o header () + é a "recomendação" do PHP / Zend). Admito que essa não é a solução mais "bonita" que já vi em termos de consistência de sintaxe, mas o que poderia ser melhor?

Como minha pergunta foi marcada como duplicada, acho que não há problema em postar por que NÃO omitir a tag de fechamento ?>pode ser por alguns motivos desejados.

• Com a <?php ... ?>fonte de instruções de processamento completa, a sintaxe ( ) PHP é um documento SGML válido, que pode ser analisado e processado sem problemas com o analisador SGML. Com restrições adicionais, também pode ser XML / XHTML válido.

Nada impede que você escreva um código XML / HTML / SGML válido. A documentação do PHP está ciente disso. Excerto:

Nota: Observe também que, se você estiver incorporando PHP dentro de XML ou XHTML, precisará usar as tags <? Php?> Para permanecer em conformidade com os padrões.

É claro que a sintaxe do PHP não é SGML / XML / HTML estrita e você cria um documento que não é SGML / XML / HTML, assim como você pode transformar HTML em XHTML para ser compatível com XML ou não.

• Em algum momento, convém concatenar fontes. Isso não será tão fácil quanto cat source1.php source2.phpse você tiver inconsistência introduzida ao omitir as ?>tags de fechamento .

• Sem ?>isso, é mais difícil saber se o documento foi deixado no modo de escape do PHP ou no modo de ignorância do PHP (a tag PI <?phppode ter sido aberta ou não). A vida é mais fácil se você deixar seus documentos consistentemente no modo de ignorar o PHP. É como trabalhar com documentos HTML bem formatados em comparação com documentos com tags não fechadas, muito aninhadas etc.

• Parece que alguns editores como o Dreamweaver podem ter problemas com o PI deixado em aberto [1] .

Se eu entendi a pergunta corretamente, isso tem a ver com o buffer de saída e o efeito que isso pode ter sobre as tags de fechamento / encerramento. Não tenho certeza de que seja uma pergunta totalmente válida. O problema é que o buffer de saída não significa que todo o conteúdo seja retido na memória antes de enviá-lo ao cliente. Isso significa que parte do conteúdo é.

O programador pode intencionalmente liberar o buffer ou o buffer de saída. A opção de buffer de saída no PHP realmente muda como a tag de fechamento afeta a codificação? Eu argumentaria que não.

E talvez seja por isso que a maioria das respostas retornou ao estilo e à sintaxe pessoal.

Existem 2 possíveis usos do código php:

1. Código PHP, como definição de classe ou definição de função
2. Use PHP como uma linguagem de modelo (ou seja, em visualizações)

no caso 1. a tag de fechamento é totalmente inútil, também gostaria de ver apenas 1 (uma) tag aberta de php e tag de fechamento NO (zero) nesse caso. Essa é uma boa prática, pois torna o código limpo e separa a lógica da apresentação. Para o caso de apresentação (2), alguns acharam natural fechar todas as tags (mesmo as processadas pelo PHP), o que gera confusão, já que o PHP possui dois casos de uso separados, que não devem ser misturados: lógica / cálculo e apresentação