Por que alguém omitiria a marca fechada?


374

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?


3
possível duplicata [por que em alguns scripts que omitir a tag de fechamento php>?] ( stackoverflow.com/questions/3219383/... )
Gordon

@ Christian - Você quer dizer que usar o output_buffering é preguiçoso ou deixar de lado ?>é preguiçoso?
precisa

4
@Gordon - eu não acho que seja um dup, o OP conhece os motivos ostensivos, só quer saber se ele foi completamente resolvido com o buffer de saída.
El Yobo 12/12

5
Uma pergunta melhor seria: por que incluir a tag close? Código é mau. O melhor código é nenhum código. Se um problema puder ser eliminado em vez de resolvido com código, é melhor do que ter código. Nesse caso, não há nenhum problema que precise ser resolvido. O código funciona bem sem a tag close.
still_dreaming_1

19
Oh Deus, isso não é o lugar para os guias vs espaços guerra santa, lol :)
Kevin Wheeler

Respostas:


322

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.

Regex ligeiramente diferente que eu usei para encontrar as tags com o Netbeans IDE, para a caixa de diálogo Localizar e substituir: \?>(?s:.){0,10}\Z Breve explicação: changeset.hr/blog/misc
Miscellaneous

@Cek, ele pega qualquer texto -inclusive code-que é de 10 caracteres ou menos depois ?>: por exemplo, ele corresponde -e seria Delete ?> Hellono <?php echo "test"; ?> Hello. Queremos limpar apenas as tags fechadas.
Halil Özgür

6
Pior, o apache 2.4.6 com PHP 5.4 na verdade falha de seg em nossas máquinas de produção quando há espaço vazio atrás da tag de fechamento. Eu só perdi horas até finalmente estreitar o bug com strace. Aqui está o erro que apache lança: [core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11).
Artem Russakovskii

3
@INTPnerd Ah, a pergunta e a maioria das respostas se referem à coisa do cabeçalho, então eu assumi que qualquer pessoa que estivesse lendo este tópico teria uma idéia sobre isso. O problema subjacente e a causa real dos problemas em muitas das respostas aqui são espaços em branco desnecessários depois ?>, o que (como qualquer saída) faz com que os cabeçalhos sejam enviados assim que são produzidos. Não há "cabeçalhos HTML" (além da <header>tag HTML5 não relacionada ).
Halil Özgür

2
Isso deve funcionar, independentemente do modificador global: \ s * \?> \ S * \ Z Observe o '\ Z' no final. Ele garante que você esteja capturando uma tag de fechamento php se e somente se for o último espaço não em branco no final do arquivo.
Erutan409

122

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.


2
> qualquer programador com meia mente pode se lembrar de não adicionar espaço em branco extra. Melhor ainda, qualquer desenvolvedor com 1/2 mente pode adicionar um gancho de pré-confirmação ao SVC para que todos os espaços à direita sejam excluídos automaticamente: sem problemas, sem confusão.
BryanH

6
@BryanH, até você ter um arquivo onde o espaço em branco à direita é absolutamente necessário, mas isso é muito raro.
precisa saber é o seguinte

11
Você está certo, é claro. Confira a resposta de mario para algumas alternativas muito legais.
precisa saber é o seguinte

"O motivo pelo qual você não deve deixar de lado a tag de fechamento do php é porque isso 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." No Windows, talvez. Em sistemas do tipo UNIX, todos os arquivos terminam com \ ne programas são adicionados a você. EDIT: Aha! Como observado abaixo por @mario, o PHP come isso, na verdade.
Andrea

2
Ainda mais significativo é que mesmo programadores com o dobro de uma mente tripla são humanos e esquecem algumas coisas.
Sebastian Mach

57

É 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.


7
Sim, frases bruscas e provocantes atraem votos negativos. Pelo que li com o tempo, deixar de fora o token de fechamento não tem absolutamente desvantagens, desde que você não trabalhe com software que não possa lidar com isso. A menos que você pode realmente provar que omitindo fichas de fechamento é ruim e uma coisa muito Noob fazer, minhas estadias downvote;)
jpeltoniemi

2
@ Pichan: Eu vou permitir. Mas presumo que você não tenha entendido bem o que está sendo dito aqui. Evitar e evitar são duas coisas diferentes. E os problemas parcialmente resolvidos são o resultado do aconselhamento sobre o óleo de cobra.
Mario

6
@ mario: É uma recomendação de estilo de codificação para iniciantes . Discordo. Todo o Zend Framework omite as tags de fechamento. Eu acho que é uma escolha muito pessoal, eu realmente prefiro deixar minha <? Php aberto e eu não me sinto um novato :)?
Daniele Vrut

11
E o HTML? É então necessário? Por exemplo <?php if($var): ?>Hello World<?php endif; ?>??? Estou genuinamente curioso, pois não é especificamente mencionado.
precisa saber é o seguinte

11
@WASasquatch Sim. Se você alternar entre os modos HTML e PHP, precisará de tokens próximos em qualquer caso. (Não é realmente relevante para a questão original aqui.)
mario

22

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.


10
Se não é uma tag, o que é?
Danidacar

Você pode fornecer um exemplo? Talvez minha configuração de php esteja danificada, mas não consigo reproduzir o problema.
Danidacar

2
arquivo1.php: <?php $i = 1; ?> então file2.php:<?php include 'file1.php'; header('Location: http://www.google.com');?>
Quentin

11
Também existem desvantagens no buffer de saída; ele usa mais memória no servidor (como toda a saída deve ser armazenada na RAM até que seja emitida; sem o buffer, ela é executada imediatamente). Também é sempre um pouco mais lento. Nenhum desses problemas ocorrerá na maioria dos casos, mas sou preguiçoso de qualquer maneira, então por que não deixar a marca de fechamento? Eu uso phpcspara garantir que a marca de fechamento é deixado de cada um de meus arquivos e, em seguida, eu não me preocupo com o buffer de saída :)
El Yobo

11
@danip: Se você definiu o sinalizador output_buffer no arquivo de configuração php, não foi possível reproduzir este problema.
Jichao

16

É 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 .


3
É por isso que eu coloco seguro em itálico. Ele evita erros que podem custar muito tempo para um espaço indesejado após o ?>. seguro pode não ser a boa palavra aqui. Enfim, ele não corrige nada (não é um código ruim para evitar coisas, e echoaqui teria sido um código ruim), mas / e ainda é válido. Prove que estou errado nisso.
Shikiryu

Eu não te votei, aliás. Mas meu argumento é compatível com o seu. Não conserta nada. Eu nunca disse que não é válido, então não preciso provar nada.
Christian

11
Chouchenos, aposto que você quis dizer seguro, em vez de seguro. IMHO um negativo por isso era demais. Trouxe você de volta à estaca zero. ;-) Afinal, você não estava dizendo a coisa errada. Até as diretrizes de desenvolvimento do PHP incentivam você a fazer isso. Na verdade, é muito melhor confiar na omissão de fechamento de tags, em vez de armazenar buffer de saída, por exemplo. O último seria como desativar o display_errors. Trapaça pura. E uma boa chance de seu aplicativo não ser portátil. Eu realmente acho que, como regra, é melhor não confiar no buffer de saída.
Maraspin

11
Eu não quero questionar pessoas que gostam de colocar ?>no final de um arquivo somente php. mas você já teve a necessidade de depurar algum erro causado por espaços à direita? Além disso, nem todos os servidores estão configurados da mesma maneira, especialmente quando você se move para outro host, capturar esses erros consome muito tempo. Se você quer colocar ?>apenas fazê-lo, se você também adicionar um pouco de espaço à direita e sua necessidade equipe para depuração que estar pronto para culpa em git ^^
CoffeDeveloper

16

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


10

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


23
Essa tag "nunca é permitida" provavelmente é um padrão de codificação do Zend, mas não é uma regra de sintaxe para a formatação de arquivos PHP.
Matt Huggins

9

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 ...


11
Isto é completamente falso. O PHP NÃO converte essas tags em XML e, portanto, nenhum desequilíbrio está sendo gerado.
Drachenkatze 22/10/2013

7
@ Felicitus: Eu acho que você perdeu a parte que diz: "Não estou dizendo que isso é importante. É apenas uma visão que não vejo expressa com muita frequência, então qual o melhor lugar para compartilhá-lo ..." Não é sobre PHP traduzindo tags em XML. É sobre o que acontece quando um arquivo é interpretado em um contexto XML (como HTML, ou editores, etc) ... Mas o ponto perdido ...
ircmaxell

7

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)

6

"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.


11
Eu tive um cliente reclamar porque o analisador XML estava recusando nossa saída quando havia uma linha em branco extra no início. Pior, isso estava acontecendo apenas em um servidor em sete com uma linha extra após a tag de fechamento em um arquivo de configuração não revisto.
eswald

5

Prós

Contras

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?


2

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] .


0

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.


0

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

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.