É uma má prática usar a tag <? = No PHP?


190

Encontrei essa tag PHP <?= ?>recentemente e reluto em usá-la, mas é tão difícil que eu queria que você entendesse. Sei que é uma má prática usar tags curtas <? ?>e que devemos usar tags completas <?php ?>, mas e essa <?= ?>:?

Isso economizaria algumas digitações e seria melhor para a legibilidade do código, IMO. Então, em vez disso:

<input name="someVar" value="<?php echo $someVar; ?>">

Eu poderia escrever assim, que é mais limpo:

<input name="someVar" value="<?= $someVar ?>">

O uso deste operador é mal visto?


11
O problema com esse tipo de pergunta é que é muito opinativo. "Tecnicamente" não existe um caminho certo ou errado. Alguns argumentam a favor, outros contra, são todas as suas preferências. Então, no final, depende de você.
precisa saber é

Evite a tag de fechamento de qualquer forma, se você puder - ou seja, o arquivo contém apenas código php (sem html etc). Se você tiver uma marca de fechamento, qualquer caractere depois dela será exibido no navegador (para um aplicativo Web) - o que pode resultar em problemas muito difíceis de depurar. Para obter mais informações: stackoverflow.com/a/4453835/49560
dharm0us

Relacionado a não-opinião: Cuidado porque echoleva muito facilmente ao XSS, e você deve confiar melhor no método de eco dedicado ao contexto (ou seja: ter um function html($x) { echo htmlentities($x,...); }e un em html($someVar);vez de echo $someVarou usar echo json_encode($x);para o contexto JS). Isso torna as <?=tags uma prática inadequada, porque significa que você escapou do conteúdo da variável em HTML em outro local e, portanto, outro local deve saber magicamente que essa variável deve ser escapada ao HTML porque é ecoada no contexto HTML.
Xenos 23/03

Respostas:


211

História

Antes que o trem de desinformação fique muito longe da estação, há várias coisas que você precisa entender sobre as tags curtas do PHP.

O principal problema com as tags curtas do PHP é que o PHP conseguiu escolher uma tag ( <?) usada por outra sintaxe, XML .

Com a opção ativada, você não conseguiu gerar a declaração xml sem gerar erros de sintaxe:

<?xml version="1.0" encoding="UTF-8" ?>

Esse é um grande problema quando você considera o quão comum é a análise e o gerenciamento de XML.

Que tal <?=?

Embora <?cause conflitos com xml, <?= não . Infelizmente, as opções para ativá-lo e desativá-lo estavam vinculadas short_open_tag, o que significava que, para obter o benefício da tag curta de eco ( <?=), você precisava lidar com os problemas da tag curta aberta ( <?). Os problemas associados à marca aberta curta eram muito maiores do que os benefícios da marca de eco curto; portanto, você encontrará um milhão e meio de recomendações para short_open_tagdesativar, o que você deve fazer .

Com o PHP 5.4, no entanto, a tag de eco curto foi reativada separadamente da short_open_tagopção. Eu vejo isso como um endosso direto à conveniência de <?=, pois não há nada de fundamentalmente errado com ele por si só.

O problema é que você não pode garantir isso <?=se estiver tentando escrever um código que possa funcionar em uma variedade maior de versões do PHP.

ok, agora que está tudo fora do caminho

Você deveria usar <?=?

fluxograma sobre se deve ou não usar a tag de eco curto


71
Eu discordo do seu diagrama rápido. A resposta correta é 99,99% SIM, porque a maioria dos ambientes de produção está configurada para usar tags curtas. Supondo que você estragou tudo e eles remover <?=no futuro, você pode corrigi-lo em menos de um minuto, não importa quantos milhares de arquivos de usá-lo, basta fazer uma busca em todo o projeto e substituir de <?=para <?php echo . Minha resposta é não se preocupe e apenas use , os benefícios superam as consequências. <?=não é mais visto como uma marca curta, o próprio Rasmus Lerdorf se comprometeu.
Dukeofgaming

32
@dukeofgaming, onde você está obtendo seus dados sobre os ambientes de produção configurados para usar tags curtas? Desativá-los é uma das configurações mais sugeridas que ouvi falar, perdendo apenas para desativar as aspas mágicas. Também não faria absolutamente nenhum sentido ter um ambiente de desenvolvimento diferente da produção.
precisa saber é o seguinte

4
As tags curtas foram ativadas por padrão até 5.3 php.net/manual/en/ini.core.php#ini.short-open-tag , a maioria dos serviços de hospedagem que conheço o suportava sem problemas e esse foi um dos motivos do framework Kohana usado para encorajá-lo. <?=estará sempre ativado ( stackoverflow.com/a/6064813/156257 ) e na maioria das vezes eles costumavam estar. Você pode provar que estou errado, verificando com seu host se: eles estão desabilitados e usam PHP <5.3 e se não permitem que a configuração seja substituída pelos usuários ou mediante solicitação especial; se todo o anterior é falso, por todos os meios se preocupe <?=.
dukeofgaming

6
Você não está preocupado com a <?=remoção e nem eu. Outros podem estar, e se estiverem, não precisam usar <?=. Algumas pessoas têm um medo irracional de usar certos recursos do idioma ( como deixar de fechar as tags no php ).
precisa saber é o seguinte

8
Esse é exatamente o meu ponto: não há necessidade de se preocupar . Eu apenas colocaria "Você está preocupado?" - sim -> "Vá em frente e use-os, não há necessidade de se preocupar". Também parece que você está sugerindo que deixar de fechar tags é uma prática ruim, o que não é.
Dukeofgaming

29

Tirando o pó do meu chapéu PHP

Eu definitivamente preferiria o uso de <?= $someVar ?>mais verboso echo(simplesmente preferência pessoal). A única desvantagem do AFAIK é para usuários que executam a versão anterior à 5.4.0. Nesse caso, short_open_tagdeve ser ativado no php.ini .

Agora, tendo dito isso, se o seu projeto não for um SO, é um ponto discutível. Se for, eu documentaria o fato de que short_open_tags deve estar ativado ou use a mais portátil das duas soluções.


11
Nitpick: Embora não <?=seja afetado pelo short_open_tagPHP 5.4, <?ainda é e se você tem o hábito de usar tags de formato curto, é muito fácil esquecer o que é suportado em qual versão.
precisa

7
@YannisRizos É bom distinguir <?=como "Estou produzindo uma variável agora" para uso no estilo de modelo e <?phpcomo "Estou executando muito código agora". Eu sugiro nunca usar <?, mas que ambos <?=e <?phpestão bem.
precisa saber é o seguinte

2
+1 porque Rasmus Lerdorf apoia a marca abreviada <? =. Eu assisti a uma de suas palestras sobre o PHP 5.4 (que será lançado em breve). É por isso que, desde o PHP 5.4.0, a tag <? = Está sempre disponível. Eu já vi muitos códigos anteriores ao PHP 5.4 que a tag <? = É usada no modo de exibição de um aplicativo MVC, mas o <? Php ...?> É usado nos arquivos sem visualização.
Programador

@ Jason Não é isso que estou dizendo. "Rasmus endossa foo" não é um argumento, "Rasmus endossa foo por essa e por essa razão", no entanto.
yannis 6/06/12

2
@Yannis Rizos "Rasmus concorda com isso por esse e por esse motivo", no entanto. Obrigado pela tutela, mas meu raciocínio foi desde que Rasmus Lerdorf a apoia, sendo o criador da linguagem e ainda tendo influência no desenvolvimento do PHP, foram feitas alterações para tornar a tag <? = Sempre disponível. Isto é o que eu deveria ter adicionado ao meu comentário original "Portanto, a prática de usar <? = Nas visualizações provavelmente se tornará ainda mais difundida". Dang, eu vou precisar de triplicar verificar os meus comentários por enquanto em ... pontos ...
programador de

21

Você definitivamente deve tentar evitar tags de formato curto, seja <?ou não <?=.

O principal motivo técnico é a portabilidade, você nunca pode ter certeza de que as tags de formato curto funcionarão para todas as configurações, pois podem ser desativadas, procurando a short_open_tagdiretiva. Mas você sempre pode estar absolutamente certo de que a forma longa funcionará em todos os lugares.

Isso economizaria algumas digitações e seria melhor para a legibilidade do código, IMO.

Isso também é um mau hábito. Eu realmente não posso te dizer o que você acha mais legível, mas sou febrilmente contra usar a legibilidade do código como uma desculpa para poupar algumas teclas. Se você está preocupado com a legibilidade, opte por um mecanismo de modelo:

<input name="someVar" value="{someVar}">

é muito mais legível nos dois exemplos.

Por fim, vale a pena notar que as tags de formato curto são explicitamente desencorajadas pelos principais projetos PHP, por exemplo, PEAR e Zend Framework .


14
+1 para modelos. -1 para portabilidade. É uma linguagem do lado do servidor. Os desafios que você precisa focar em um servidor são: escalabilidade e segurança. Seria uma surpreendentemente má idéia para investir tempo sério para ter certeza que ele seria executado em várias plataformas ... (apenas no caso!) ...
riwalk

3
@ Stargazer712 Hm? A única coisa que você precisa fazer é usar o padrão <?phpe, em echovez de <?e <?=, você considera isso um período sério? E o que acontece quando você move seu projeto para um servidor em que, por algum motivo, as tags curtas estão desabilitadas?
precisa

13
@ Yannis: esses poucos personagens podem não parecer muito, mas na IMO eles adicionam muito barulho.
precisa

8
Eu acho que deve ser mencionado que o objetivo original do PHP era ser uma linguagem de modelo . Adicionar outro mecanismo de template (mais inchaço) sobre o PHP não flutua no meu atum. Basta seguir as boas práticas (algumas boas dicas estão aqui stackoverflow.com/questions/62617/… ) ao codificar PHP misturado com HTML e pronto.
Programador

2
@ Yannis Rizos Sim, deve ser mencionado porque pessoas novas no PHP podem pensar que são obrigadas a usar o mecanismo de modelo [whizbang] em seus projetos PHP sem considerar o uso de PHP puro. Devo fazer apenas o processamento de texto em Perl , talvez não, mas acho que agora o Perl é muito bom em processamento de texto - da mesma forma com PHP e modelos.
programador

15

A documentação do PHP diz claramente que você pode usar tags de eco curtas com segurança:

5.4.0 The tag <?= is always available regardless of the short_open_tag ini setting.

Embora isso seja para o PHP versão 5.4 e superior, todos deveriam pelo menos usar este. Eu os preferiria apenas para fins de modelo.


10

Razões para usar tags curtas:

  • Eles são mais curtos.

Razões para não usar tags curtas:

  • Eles introduzem mais uma pegadinha de configuração - enquanto você controla o servidor a maior parte do tempo em um contexto profissional, se você planeja liberar seu código para o público em geral, as tags curtas podem ser quebradas de maneira irreparável para as pessoas que o usam, por exemplo, em hospedagem compartilhada .
  • Eles tornam muito fácil soltar cordas não higienizadas casualmente em sua saída. Isso é assustador, pois pode introduzir vulnerabilidades XSS. Embora as tags longas não façam nada diretamente para impedir isso, elas sinalizam para o programador que talvez o que estejam fazendo não seja a coisa certa, e devem começar a usar um sistema de modelos que manipule automaticamente a codificação HTML para eles agora . A produção de strings dinâmicos com tags longas é dolorosa, o que é uma coisa boa (educativa).

Essa é a resposta para aceitar o IMO, mesmo que os modelos não tornem tudo o XSS seguro (os dados do usuário no atributo src de um script sempre serão inseguros) e não sei se o mecanismo do modelo está ciente do contexto de eco adequado; e se a variável PHP acabar em um conteúdo de tag de script? Em um SVG incorporado no HTML?
Xenos 23/03

@ Xenos claramente, isso depende do sistema de gabaritos em questão e não há bala de prata; mas a maioria deles reduz a superfície de erros e o número de cenários em que é necessária a diligência manual (a fonte mais importante de erros de segurança). "Não coloque conteúdo dinâmico em tags de script" é mais fácil de seguir (e auditar) do que "verifique se todo o conteúdo dinâmico está codificado em HTML corretamente em qualquer lugar".
tdammers 04/04

4

Eu acho que a <?=versão é uma prática boa / aceitável, desde que você a use apenas para saída final de variáveis ​​e evite chamadas de função ou lógica ternária que não estejam diretamente relacionadas à apresentação dos dados.

Certamente é muito melhor do que em <? echo($x); ?>qualquer lugar.

A longo prazo, você pode pesquisar mecanismos de modelagem, como o Smarty .


3
O Smarty já foi o mecanismo de modelos, mas agora é uma bagunça desatualizada e inchada, e você deve realmente ficar claro.
precisa


-3

Para ser sincero, acho que ecoar um resultado, seja qual for o método (moda antiga ou nova), é algo bastante obsoleto, enquanto o MVC comemora 33 anos.

Eu diria que sim, essa é uma boa prática para encapsular os dados do servidor de entrada (php) em um documento XML e processá-lo em sua camada de aplicativo / cliente, economizando assim a idéia de usar essa marca.


11
Na verdade, o MVC comemora 33 anos, foi esboçado em dezembro de 1979 neste artigo .
precisa saber é

Sim, eu ainda estou no ano 2000, o meu erro :-)
sebas

11
um ... modelo ... o modelo é obsoleto? O modelo e o MVC são mutuamente exclusivos?
Tim Seguine
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.