As tags curtas do PHP são aceitáveis ​​para uso?

522

Aqui estão as informações de acordo com a documentação oficial :

Existem quatro pares diferentes de tags de abertura e fechamento que podem ser usadas no PHP. Dois desses, <?php ?> e <script language="php"> </script>, estão sempre disponíveis. Os outros dois são tags curtas e tags de estilo ASP, e podem ser ativados e desativados no arquivo de configuração php.ini. Como tal, embora algumas pessoas achem convenientes as tags curtas e as tags de estilo ASP, elas são menos portáteis e geralmente não são recomendadas .

Na minha experiência, a maioria dos servidores não têm tags curtas habilitado. Digitando

<?=

é muito mais conveniente do que digitar

<?php echo 

A conveniência dos programadores é um fator importante, por que eles não são recomendados?

MDCore
fonte
61
Para responder à pergunta why, eu citaria o guia de certificação do Zend PHP 5: "As tags curtas foram, por um tempo, o padrão no mundo PHP; no entanto, elas têm a grande desvantagem de entrar em conflito com os cabeçalhos XML e, portanto, têm um pouco caído no caminho. "
Fluffy
7
Qual é o caso de uso em que esse problema surge, isso significa que é uma dor para os desenvolvedores gerar XML usando PHP?
9136 Jon Z
9
Digamos que você tenha documentos XML que deseja publicamente, mas deseja que os documentos sejam analisáveis ​​em php por qualquer motivo, para tornar o arquivo .xml analisável pelo navegador. Você usa tags curtas para ativá-las e, de repente, o documento XML é analisado pelos cabeçalhos XML, quebrando coisas. Me deixou louco tentando descobrir isso há muito tempo. Desde códigos curtos foram desativados em qualquer servidor eu corro e qualquer equipe com quem trabalhei teve de recorrer ao código não curto
thenetimp
43
No PHP 5.4.0, a diretiva short_open_tag não inclui a tag short echo <?= $example;?> ! Isso é muito importante, pois o uso de todas as outras tags curtas é considerado inútil. De qualquer forma, o uso da tag de eco curto é incentivado a partir de agora. Ele fornece uma base de código mais suave e organizada - esp. em visualizar arquivos. Portanto, para PHP> = 5.4.0 <?= ?> pode ser usado sem configuração short_open_tag . Por favor, não use as outras tags curtas no seu código. O código-Deuses ficam muito irritados quando você faz isso ...
Borislav Sabev
6
Vou adicionar isso como um comentário rápido, porque já existem muitas respostas longas: <?não é usado apenas em XML para a <?xml version="1.0" ?>declaração de abertura ; é a sintaxe geral para "instruções de processamento", sendo o segundo exemplo mais comum <?xml-stylesheet ... ?>. <?phppode realmente ser considerada uma instrução de processamento válida, como pode <?=(conforme permitido em 5.4 ou superior), mas reivindicar o todo <?também cria conflitos desnecessários entre as sintaxes.
IMSoP 5/08/13

Respostas:

374

Eles não são recomendados porque é uma PITA se você precisar mover seu código para um servidor em que não é suportado (e você não pode ativá-lo). Como você diz, lotes de hosts compartilhados fazer shorttags apoio, mas "muitos" não é todos eles. Se você deseja compartilhar seus scripts, é melhor usar a sintaxe completa.

Concordo que <?e <?=são mais fáceis para os programadores do que <?phpe, <?php echomas é possível localizar e substituir em massa desde que você use o mesmo formulário a cada vez (e não se arrisque nos espaços (por exemplo: <? phpou <? =)

Eu não compro legibilidade como uma razão. Os desenvolvedores mais sérios têm a opção de destacar a sintaxe disponível para eles.

Como o ThiefMaster menciona nos comentários, a partir do PHP 5.4, as <?= ... ?>tags são suportadas em todos os lugares, independentemente das configurações de shorttags . Isso deve significar que eles podem ser usados ​​com segurança em código portátil, mas isso significa que há uma dependência do PHP 5.4+. Se você deseja oferecer suporte à versão anterior à 5.4 e não pode garantir atalhos, ainda precisará usar <?php echo ... ?>.

Além disso, você precisa saber que as tags ASP <%,%>, <% = e a tag de script são removidas do PHP 7 . Portanto, se você deseja oferecer suporte a códigos portáteis de longo prazo e deseja mudar para as ferramentas mais modernas, considere alterar essas partes do código.

Oli
fonte
91
Então, a explicação é: eles são ruins porque não são suportados? Mas por que eles não são suportados? Porque eles não fazem parte da especificação? Ok, mas por que eles não fazem parte da especificação? Estou um pouco decepcionado com esta resposta.
1911 Josef Sábl
61
Não estou aqui para discutir as "grandes questões", como por que estamos aqui, como tudo começou etc. O suporte a atalhos não é garantido em servidores compartilhados e está sendo removido completamente na próxima versão principal. É tudo o que você precisa saber.
Oli
39
PHP obrigatório é um mecanismo de modelo. : P
Erro de sintaxe
49
Tags curtas não estão sendo eliminadas. Somente tags curtas no estilo ASP.
Brian Lacy
46
No futuro (muito próximo) do PHP 5.4, o uso de <? = Será separado se short_open_tags estiver ativado ou desativado. <? = não está sendo eliminado, pelo contrário, agora é considerado uma peça fundamental da linguagem.
Griever
175

Eu gosto muito de <?=$whatever?>deixar isso para lá. Nunca tive problema com isso. Vou esperar até que ele me morde na bunda. Com toda a seriedade, 85% dos (meus) clientes têm acesso ao php.ini nas raras ocasiões em que são desligados. Os outros 15% usam provedores de hospedagem tradicionais e praticamente todos eles os habilitam. Eu os amo.

Paolo Bergantino
fonte
41
@B Seven Se você tentar evitar todos os problemas teóricos que possam surgir, seu código será quase definitivamente ineficiente e com erros. Até o grupo PHP concordar em eliminar gradualmente as tags curtas [não as tags ASP], a preocupação de ser picado é muito menor e a solução potencial muito mais simples do que outras coisas que você pode gastar seu tempo "consertando".
SamGoody
18
se ele te morde, mover para uma melhor hospedagem
Lie Ryan
4
Eu realmente não concordo em não usar algo, pois pode não ser suportado. Não devemos usar nenhum dos outros recursos que podem não ser suportados em um servidor? MYSQL vs MYSQLI? Você desperdiçará seu tempo aos poucos, repetidamente escrevendo tags longas apenas para evitar uma pequena chance de gastar um pouco de tempo para mudar para um host melhor.
Dean Ou
2
@BSeven, quer dizer que você não usa nenhuma extensão PHP, exceto as padrão fornecidas?
Pacerier
143

A partir do PHP 5.4, o atalho de eco é um problema separado das tags curtas, pois o atalho de eco sempre estará ativado. É um fato agora:

Portanto, o próprio atalho de eco ( <?=) é seguro para uso agora.

dukeofgaming
fonte
19
Eu diria que este é o único "atalho" necessário. <?phppode ser usado no início de todos os arquivos de classe e você tem <?=suas visualizações. ganha-ganha.
Xeoncross
6
So the echo shortcut itself (<?=) is safe to use... desde que você esteja confortável exigindo o PHP 5.4. Os aplicativos PHP amplamente distribuídos (como o wordpress) não têm o luxo de exigir a versão 5.4, e até continuaram a oferecer suporte ao PHP 4 até 2011 - um total de 7 anos após o lançamento do PHP 5. Se você estiver em um local como o facebook, onde todas as instalações do seu software são operadas diretamente pela própria empresa, exigir o suporte à 5.4 é muito mais fácil do que se você estiver trabalhando em um projeto como o wordpress.
Frank Farmer
@dukeofgaming, Wow boa captura, não sabia que suas revisões SVN são acessíveis na web.
Pacerier
82

O problema com toda essa discussão está no uso do PHP como uma linguagem de modelagem. Ninguém está argumentando que as tags devem ser usadas nos arquivos de origem do aplicativo.

No entanto, a sintaxe incorporável do PHP permite que ele seja usado como uma poderosa linguagem de modelos, e os modelos devem ser o mais simples e legível possível. Muitos acharam mais fácil usar um mecanismo de modelagem de complemento muito mais lento, como o Smarty, mas para os puristas entre nós que exigem renderização rápida e uma base de código pura, o PHP é a única maneira de escrever modelos.

O argumento SOMENTE válido CONTRA o uso de tags curtas é que elas não são suportadas em todos os servidores. Comentários sobre conflitos com documentos XML são ridículos, porque você provavelmente não deveria misturar PHP e XML de qualquer maneira; e se estiver, você deve usar o PHP para gerar sequências de texto. A segurança nunca deve ser um problema, porque se você estiver colocando informações confidenciais, como credenciais de acesso ao banco de dados, dentro de arquivos de modelo, então você terá problemas maiores!

Agora, então, quanto à questão do suporte ao servidor, é preciso ter consciência da plataforma de destino. Se a hospedagem compartilhada é um alvo provável, tags curtas devem ser evitadas. Mas para muitos desenvolvedores profissionais (como eu), o cliente reconhece (e de fato depende do fato) que estaremos ditando os requisitos do servidor. Muitas vezes, sou responsável por configurar o servidor.

E NUNCA trabalhamos com um provedor de hospedagem que não nos dá controle absoluto da configuração do servidor - nesse caso, poderíamos contar com muito mais problemas do que apenas perder o suporte a tags curtas. Isso simplesmente não acontece.

Então, sim - concordo que o uso de tags curtas deve ser cuidadosamente ponderado. Mas também acredito firmemente que SEMPRE deve ser uma opção e que um desenvolvedor que esteja ciente de seu ambiente deve se sentir livre para usá-los.

Brian Lacy
fonte
6
Se, por algum motivo, você tivesse o apache configurado para passar arquivos .xml para mod_php, a coisa <? Xml seria uma dor de cabeça com tags curtas. Mas isso é obviamente uma configuração bizarra.
Frank fazendeiro
3
A modelagem linguagem que não pode ser incorporado sem soluções alternativas em alguns tipos de documentos de saída é uma grande falha. A única razão pela qual eu não deveria ter um modelo XML com código PHP e tags curtas é porque não funciona, não porque não faz sentido.
Vinko Vrsalovic
8
Não é uma "grande falha" tirar proveito dos benefícios do PHP como uma linguagem de modelagem rápida e conveniente. Como eu disse antes, é uma questão de avaliar os benefícios e as desvantagens e escrever código de uma maneira que acomode a abordagem escolhida. Não descarte categoricamente uma abordagem válida apenas porque ela não funciona em um cenário específico (que pode ser facilmente contornado).
Brian Lacy
5
Não estou descartando categoricamente nenhuma abordagem válida (veja minha resposta à pergunta.) Você é quem dispensa categoricamente o PHP em XML, cito: "você não deveria misturar PHP e XML de qualquer maneira". Além disso, a grande falha a que eu estava me referindo foi a decisão de usar <?como uma marca curta, porque isso leva a soluções feias no XML. Dito isto, concordo que se trata de pesar benefícios e desvantagens, e que, se você souber o que está fazendo, certamente poderá fazê-lo. Mas isso não faz <?uma boa escolha.
Vinko Vrsalovic
3
Estou um pouco atrasado para a festa, mas gosto muito desta resposta e isso reflete minha experiência com a situação. Embora tenhamos alguma discordância sobre o assunto em nosso escritório, posso dizer que, com o trabalho quase diário no php por muitos anos, nunca me deparei com isso. Quando o PHP é usado para gerar XML, na minha experiência, ele sempre esteve no contexto de conteúdo altamente dinâmico, que nunca foi modelado diretamente via PHP; portanto, o problema simplesmente nunca aparece.
redreinard
33

Tags curtas estão voltando graças ao Zend Framework pressionando o " PHP como uma linguagem de modelo " em sua configuração padrão do MVC . Não vejo do que se trata o debate, a maior parte do software que você produzirá durante a sua vida operará em um servidor que você ou sua empresa controlará. Contanto que você se mantenha consistente, não haverá problemas.

ATUALIZAR

Depois de trabalhar bastante com o Magento , que usa forma longa. Como resultado, mudei para a forma longa de:

<?php and <?php echo

sobre

<? and <?=

Parece uma pequena quantidade de trabalho para garantir a interoperabilidade.

Jake McGraw
fonte
8
Sou freelancer e todo o meu código vai para hospedagem compartilhada, então não há controle! :)
MDCore 22/10/08
12
Se você tiver clientes suficientes migrando para seu próprio local, a hospedagem compartilhada é insegura e instável.
Jake McGraw
2
As tags curtas que Zend estava trazendo de volta aparentemente não capturaram, pois o Zend está usando a versão longa: framework.zend.com/manual/en/zend.view.scripts.html
Gerry
3
@Gerry Eu também li isso recentemente, veja o último comentário neste tópico: Atualize .htaccess para ativar pequenas tags abertas
MrWhite
2
Você realmente deve corrigir a gramática na primeira frase após UPDATE, o que não faz sentido em sua forma atual.
redreinard
22

Porque a confusão pode gerar com declarações XML. Muitas pessoas concordam com você, no entanto.

Uma preocupação adicional é a dor que ele geraria para codificar tudo com tags curtas apenas para descobrir no final que o servidor de hospedagem final as desativou ...

Vinko Vrsalovic
fonte
A declaração XML não causará confusão de qualquer maneira, se short_tags estiver ativado?
MDCore 14/10/08
Então, em vez de emitir diretamente a declaração XML, você faz com que o PHP faça eco. Não é realmente uma boa refutação.
moo
Não é uma refutação de nada. É a única razão real que, por sua vez, é a causa da outra razão "o hoster desliga", é claro que você pode usá-lo se souber o que está fazendo, como sempre.
Vinko Vrsalovic 29/07/09
1
@macek: Estou ciente disso. Foi apenas o primeiro exemplo em que pensei. Outro, e se você incorporar PHP em um arquivo XML? Você não pode fazer isso diretamente. E não me diga a solução para esse problema também, estou ciente deles. O ponto é que existem várias maneiras de o PHP analisar um arquivo XML. Provavelmente, você pode descartá-los todos com soluções alternativas ( <?='<?xml') ou dizendo "você não deve fazer isso", mas isso não faz com que o fato de que isso aconteça desapareça.
Vinko Vrsalovic
1
como as tags curtas são uma dor se elas não funcionam? é muito fácil fazer um volume e substituir <?=por <? echo . muitos editores de texto podem facilmente fazer isso com milhares de arquivos de uma só vez.
Yamiko 6/12
20

A seguir, é apresentado o diagrama de fluxo maravilhoso do mesmo:

árvore de tomada de decisão do uso de <? =

Fonte: pergunta semelhante sobre Software Engineering Stack Exchange

Sumoanand
fonte
2
Esta é descrever se pretende utilizar a tag de eco curto, não o mesmo que os <?curtos marcas mencionadas na pergunta (embora ele usou o pré-5.4 mesma configuração config)
Alok
De fato, essa deve ser uma resposta que todos possam entender, embora as circunstâncias não sejam realmente explicadas por que você não deseja usar tags curtas em muitos casos (por exemplo, não é possível alterar o arquivo php.ini em um sistema de hospedagem compartilhada)
Björn K
14

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php tem muitos conselhos, incluindo:

enquanto algumas pessoas acham convenientes as tags curtas e as tags no estilo ASP, elas são menos portáteis e geralmente não são recomendadas.

e

observe que, se você estiver incorporando PHP dentro de XML ou XHTML, precisará usar as <?php ?>tags para permanecer em conformidade com os padrões.

e

O uso de tags curtas deve ser evitado ao desenvolver aplicativos ou bibliotecas destinadas à redistribuição ou implantação em servidores PHP que não estão sob seu controle, porque as tags curtas podem não ser suportadas no servidor de destino. Para código portátil e redistribuível, certifique-se de não usar tags curtas.

Oliver Charlesworth
fonte
14

Caso alguém ainda esteja prestando atenção nisso ... A partir do PHP 5.4.0, o Alpha 1 <?=está sempre disponível:

http://php.net/releases/NEWS_5_4_0_alpha1.txt

Parece que as tags curtas são (a) aceitáveis ​​e (b) vieram para ficar. Por enquanto, pelo menos ...

James Alday
fonte
5
<?=não é considerado um tag curto a partir de 5.4
T0xicCode 19/12/12
12
  • As tags curtas não são ativadas por padrão em alguns servidores da Web (hosts compartilhados etc.), portanto, a portabilidade de código se torna um problema se você precisar mudar para um deles.

  • A legibilidade pode ser um problema para alguns. Muitos desenvolvedores podem achar que <?phpchama a atenção como um marcador mais óbvio do início de um bloco de código do que <?quando você digitaliza um arquivo, principalmente se você estiver preso a uma base de código com HTML e PHP fortemente entrelaçados.

ConroyP
fonte
2
Tags curtas são ativadas em 95% dos servidores da web.
Paolo Bergantino
19
Eu não compro o argumento "legibilidade". Se você estiver usando PHP como uma linguagem de modelagem, <?= $var ?>é muito mais legível do que<?php echo $var ?>
Frank fazendeiro
2
@Paulo este pode ter mudado desde '08, mas instâncias EC2 Ubuntu e Fedora com yum install e apt-get versões do PHP têm curto-tagging desativado por padrão
Doug Molineux
2
usar marcas completos e você terá 100% :)
Elvis Ciotti
1
@FrankFarmer, acho que ele está comparando aquele sem eco. <?vs <?php.
Pacerier
11

Nota: A partir do PHP 5.4, a tag curta,, <?=agora está sempre disponível.

brunoais
fonte
5

Li esta página depois de procurar informações sobre o tópico e considero que um dos principais problemas não foi mencionado: preguiça versus consistência. As tags "reais" para PHP são <? Php e?>. Por quê? Eu realmente não me importo. Por que você gostaria de usar outra coisa quando essas são claramente para PHP? <% e%> significam ASP para mim e <script ..... significa Javascript (na maioria dos casos). Portanto, para obter consistência, aprendizado rápido, portabilidade e simplicidade, por que não seguir o padrão?

Por outro lado, concordo que as tags curtas nos modelos (e APENAS nos modelos) parecem úteis, mas o problema é que passamos tanto tempo discutindo aqui, que provavelmente levaria muito tempo para realmente desperdiçar tanto tempo digitando os três caracteres extras de "php" !!

Embora ter muitas opções seja legal, não é lógico e pode causar problemas. Imagine se toda linguagem de programação permitisse 4 ou mais tipos de tags: Javascript poderia ser <JS ou <script .... ou <% ou <? JS .... isso seria útil? No caso do PHP, a ordem de análise tende a favorecer essas coisas, mas a linguagem não é de muitas outras maneiras: lança avisos ou erros com a menor inconsistência, mas as tags curtas são usadas com freqüência. E quando tags curtas são usadas em um servidor que não as suporta, pode levar muito tempo para descobrir o que está errado, pois nenhum erro é dado em alguns casos.

Finalmente, não acho que as tags curtas sejam o problema aqui: existem apenas dois tipos lógicos de blocos de código PHP: 1) código PHP comum, 2) ecos de modelo. Para o primeiro, acredito firmemente que apenas <? Php e?> Devem ser permitidos apenas para manter tudo consistente e portátil. Para o último, o método <? = $ Var?> É feio. Por que deve ser assim? Por que não adicionar algo muito mais lógico? <? php $ var?> Isso não faria nada (e apenas nas possibilidades mais remotas poderia entrar em conflito com alguma coisa), e isso poderia substituir facilmente a sintaxe estranha <? =. Ou, se isso for um problema, talvez eles possam usar <? Php = $ var?> E não se preocupar com inconsistências.

No ponto em que existem 4 opções para abrir e fechar tags e a adição aleatória de uma tag "echo" especial, o PHP também pode ter um sinalizador "custom abrir / fechar tags" no php.ini ou .htaccess. Dessa forma, os designers podem escolher o que mais gostam. Mas, por razões óbvias, isso é um exagero. Então, por que permitir mais de 4 opções?

Daniel Ross
fonte
4

É bom usá-los quando você trabalha com uma estrutura MVC ou CMS que possui arquivos de exibição separados.
É rápido, menos código, não é confuso para os designers. Apenas verifique se a configuração do servidor permite usá-los.

Greg
fonte
4

Uma situação um pouco diferente é ao desenvolver um aplicativo CodeIgniter . O CodeIgniter parece usar as tags de atalho sempre que o PHP estiver sendo usado em um modelo / exibição, caso contrário, com modelos e controladores, ele sempre usa as tags longas. Não é uma regra rígida e rápida na estrutura, mas na maioria das vezes a estrutura e grande parte da fonte de outros usos segue esta convenção.

Meus dois centavos? Se você nunca planeja executar o código em outro lugar, use-o se desejar. Prefiro não ter que fazer uma pesquisa massiva e substituir quando perceber que foi uma ideia idiota.

patricksweeney
fonte
4

<?está desativado por padrão nas versões mais recentes. Você pode ativar isso como descrito em Habilitando tags curtas no PHP .

AnkTech Devops
fonte
Ele está desativado por padrão em versões mais antigas também, não é?
Pacerier
3

As pessoas do IMHO que usam tags curtas geralmente esquecem de escapar do que estão ecoando. Seria bom ter um mecanismo de modelo que escapa por padrão. Eu acredito que Rob A escreveu um hack rápido para escapar de tags curtas nos aplicativos do Zend Frameworks. Se você gosta de tags curtas, porque facilita a leitura do PHP. Então Smarty pode ser uma opção melhor?

{$myString|escape}

para mim que parece melhor do que

<?= htmlspecialchars($myString) ?> 
Adrian Judd
fonte
10
Para a maioria dos programadores PHP, a segunda opção faz mais sentido do que a primeira, simplesmente porque é uma função PHP real com a qual estamos familiarizados, enquanto a primeira opção é um código de pseudo-modelo que precisamos aprender sobre o PHP. O PHP já é uma linguagem de modelagem, adicionando outra linguagem de modelagem em cima dela, como o Smarty é IMO redundante.
Bug Magnet
3
Twig é um modelo de motor com html escapando ativado por padrão twig.sensiolabs.org
Mateusza
3

É preciso perguntar qual é o objetivo do uso de tags curtas.

Mais rápido para digitar

MDCore disse:

<?= é muito mais conveniente do que digitar <?php echo

Sim, ele é. Você economiza ter que digitar 7 caracteres * X vezes em seus scripts.

No entanto, quando um script leva uma hora, ou 10 horas, ou mais, para projetar, desenvolver e escrever, qual é a relevância dos poucos segundos de tempo em não digitar esses 7 caracteres aqui e ali durante o script?

Comparado com o potencial de alguns scripts principais, ou todos, não funcionarem se as tags curtas não estiverem ativadas ou estiverem ativadas, mas uma atualização ou alguém alterando a configuração do arquivo / servidor ini os interrompe, outros potenciais.

O pequeno benefício que você obtém não chega perto de compensar a gravidade dos problemas em potencial, ou seja, o site não está funcionando, ou pior, apenas partes dele não estão funcionando e, portanto, uma dor de cabeça a resolver.

Mais fácil de ler

Isso depende da familiaridade .
Eu sempre vi e usei <?php echo. Portanto, embora <?=não seja difícil de ler, não é familiar para mim e, portanto, não é mais fácil de ler .

E com a divisão do desenvolvedor de front-end / back-end (como na maioria das empresas), um desenvolvedor de front-end trabalhando nesses modelos seria mais familiar sabendo que <?=é igual a "PHP open tag and echo"?
Eu diria que a maioria ficaria mais confortável com a mais lógica. Ou seja, uma tag aberta clara do PHP e o que está acontecendo "echo" - <?php echo.


Problema na avaliação de risco = scripts completos do site ou núcleo não funcionam;

O potencial de emissão é muito baixo + a gravidade do resultado é muito alta = alto risco

Conclusão

Você economiza alguns segundos aqui e ali, sem precisar digitar alguns caracteres, mas arrisca muito e, provavelmente, também perde a legibilidade.

Da frente ou back-end programadores familiarizados com <?=são mais propensos a entender <?php echo, como eles são normais coisas PHP - padrão <?phptag aberta e muito bem conhecidos "echo".
(Mesmo os codificadores de front-end devem saber "eco" ou simplesmente não estarão trabalhando em nenhum código fornecido por uma estrutura).

Enquanto o inverso não é tão provável, é improvável que alguém deduza logicamente que o sinal de igual em uma tag curta do PHP é "eco".

James
fonte
Não tem nada a ver com digitação. É mais curto e, portanto, tem o potencial de ser mais fácil de ler . Uma pessoa acostumada a ler <?=lerá <?=mais facilmente do que uma pessoa acostumada a <?php echoler <?php echo.
Pacerier
O @Pacerier Shorter não é simplesmente mais fácil de ler. Nós somos todos diferentes. O que você quer dizer é que é mais fácil ler para você . Conforme eu respondo, como estou acostumado a <?phpver que ao longo do código muitas vezes é mais familiar para mim do que <?=- a familiaridade facilita as coisas - e não necessariamente melhor.
James
Não, eu não estou comparando você e eu, estou dizendo que uma pessoa acostumada a ler <?=lerá <?=melhor do que uma pessoa acostumada a ler <?php echoler <?php echo. Isso significa que, se tivermos duas cópias idênticas da pessoa X, e as alterarmos apenas no aspecto pelo qual uma está acostumada a ler <?=e a outra acostumada a ler <?php echo, a primeira cópia pode atingir o valor de legibilidade xdurante a leitura, usando a sintaxe desejada, enquanto a segunda cópia pode atingir o valor de legibilidade yao ler sua sintaxe desejada, em que x >= y.
Pacerier
Não, você está perdendo o ponto. Estou me referindo ao potencial do sistema, que não tem nada a ver com uma pessoa em particular. Você pode dizer que as pessoas acostumadas a digitar com teclado qwerty digitarão mais rápido com qwerty, enquanto as pessoas acostumadas a digitar com dvorak digitarão mais rápido com dvorak, mas o fato não muda que os dois sistemas tenham um potencial diferente.
Pacerier
3

Vamos encarar. PHP é feio como o inferno sem tags curtas.

Você pode habilitá-los em um .htaccessarquivo se não conseguir php.ini:

php_flag short_open_tag on
Jimmer
fonte
3
Falso. Às vezes, o servidor está configurado para negar qualquer tipo de substituição, senhor.
Alfabravo 19/03/10
17
É verdade, mas se o seu host não permitir que você substitua o htaccess, você realmente precisará de um novo host! :)
Brian Lacy
1
não funciona em interface de linha de comando e php_flag não apoiou o tempo todo
Elvis Ciotti
3

Para evitar problemas de portabilidade, inicie as tags PHP com <?phpe, caso seu arquivo PHP seja puramente PHP, sem HTML, você não precisará usar as tags de fechamento.

Kumar
fonte
2
  • Tags curtas são aceitáveis ​​para uso nos casos em que você tem certeza de que o servidor o apoiará e que seus desenvolvedores o entenderão.
  • Muitos servidores não o suportam, e muitos desenvolvedores o entenderão depois de vê-lo uma vez.
  • Uso tags completas para garantir a portabilidade, já que não é tão ruim assim.

Com isso dito, um amigo meu disse isso, em suporte a tags alternativas de estilo asp padronizadas , como em <%vez de <?, que é uma configuração no php.ini chamada asp_tags. Aqui está o seu raciocínio:

... convenções arbitrárias devem ser padronizadas . Ou seja, sempre que somos confrontados com um conjunto de possibilidades de igual valor - como a pontuação estranha que nossa linguagem de programação deve usar para se demarcar - devemos escolher um caminho padrão e segui-lo. Dessa forma, reduzimos a curva de aprendizado de todos os idiomas (ou quaisquer que sejam as coisas às quais a convenção se refere).

Parece bom para mim, mas acho que nenhum de nós pode circular pelos vagões em torno dessa causa. Enquanto isso, eu me ateria ao máximo <?php.

stereoscott
fonte
2

Eu pensei que vale a pena mencionar que a partir do PHP 7:

  • Tags PHP curtas <% … %>desapareceram
  • Guias curtas do PHP <? … ?>ainda estão disponíveis se short_open_tagconfiguradas como true. Esse é o padrão.
  • Desde o PHP 5.4, as etiquetas Short Print<?=… ?> estão sempre ativadas, independentemente da short_open_tagconfiguração.

Boa viagem ao primeiro, pois interferia em outros idiomas.

Agora não há razão para não usar as etiquetas curtas, além da preferência pessoal.

Obviamente, se você estiver escrevendo um código para ser compatível com versões herdadas do PHP 5, precisará seguir as regras antigas, mas lembre-se de que qualquer coisa antes do PHP 5.6 agora não é suportada.

Consulte: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Manngo
fonte
1
A menos que eu esteja enganado, seu primeiro ponto está incorreto. O documento diz que as tags ASP, e não as curtas do PHP, desapareceram a partir do PHP 7.0.0.
reformada
@reformed Você está absolutamente correto. Vou editar minha resposta. Obrigado
Manngo 14/11/18
1

Se você se preocupa com o XSS , deve usar a <?= htmlspecialchars(…) ?>maior parte do tempo, para que uma tag curta não faça grande diferença.

Mesmo se você encurtar echo htmlspecialchars()a h(), ainda é um problema que você tem que lembrar de adicioná-lo quase todos os tempos (e tentar manter o controle que os dados são pré-escapou, que é unescaped-mas-inofensivos só faz erros mais provável).

Eu uso um mecanismo de modelo que é seguro por padrão e grava <?phptags para mim.

Kornel
fonte
7
Se você estiver digitando "<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 vezes por dia, convém criar uma função de atalho chamada" h "como o Rails .." < ? = h ($ text)>" é apenas muito mais legível quando a digitalização de um template.
Alexander Malfait
1
É melhor realmente, mas com um modelo de motor pode ser simplesmente $ {text} ou (e você não precisa se lembrar de adicionar h ())
Kornel
7
O próprio PHP é um mecanismo de modelagem. Quando você para de usar tags curtas, ele começa a ser um mecanismo de modelagem ruim, pois fica muito detalhado.
Josef Sábl
1
@ Alexander Malfait, é uma boa dica. Mas o <? = Não é necessário. Você pode simplesmente fazer a função ecoar a string em vez de retornar, então você escreveria <? Php h ('olá')?> Não fazemos isso já quando definimos i18n? <? php _e ('')?> não é tão ruim assim.
VladFr
1

<?php ?>são muito melhores para usar, pois os desenvolvedores dessa linguagem de programação atualizam maciçamente sua linguagem principal. Você pode ver a diferença entre as tags curtas e longas.

As etiquetas curtas serão destacadas em vermelho claro, enquanto as mais longas serão destacadas em mais escuro!

No entanto, ecoar algo, por exemplo: <?=$variable;?>está bem. Mas prefira as tags mais longas.<?php echo $variable;?>

M50Scripts
fonte
1

Converter <?(sem um espaço à direita) em <?php(com um espaço à direita):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

Converter <?(com um espaço à direita) em <?php(mantendo o espaço à direita):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
Fatih Akgun
fonte
1

As tags curtas estão sempre disponíveis em php. Portanto, você não precisa repetir a primeira declaração do seu script

exemplo:

    $a =10;
    <?= $a;//10 
    echo "Hellow";//
    echo "Hellow";

   ?>

De repente você precisa usar para um único script php, então você pode usá-lo. exemplo:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>
GaziAnis
fonte
1

A partir de 2019, discordo de algumas respostas aqui. Eu recomendo usar tags longas

<?php /* code goes here */ ?>

ou tags de eco curtas

<?= /* code goes here */ ?>

Razão: Eles são recomendados pelo padrão básico de codificação PSR-1

Outras tags curtas, como <? /* code goes here */ ?>não são recomendadas.

A especificação diz:

O código PHP DEVE usar as tags longas ou as tags de eco curto; NÃO DEVE usar as outras variações de tags .

Blackbam
fonte
1

3 tags estão disponíveis no php:

  1. tag de formato longo que <?php ?>não precisa direcionar nenhuma configuração
  2. short_open_tag <? ?> disponível se a opção short_open_tag no php.ini estiver ativada
  3. encurtar tag <?= desde php 5.4.0 está sempre disponível

do php 7.0.0 asp e tag de script são removidos

GaziAnis
fonte
Isso não responde à pergunta.
RalfFriedl
-5

Não, e eles estão sendo eliminados pelo PHP 6, portanto, se você aprecia a longevidade do código, simplesmente não os use ou as <% ... %>tags.

coderGeek
fonte
4
Já vi outras postagens no blog que dizem que não serão preteridas, apenas as tags curtas no estilo ASP.
MDCore 16/10/08
22
Parece que esta resposta está incorreta, de acordo com este link da reunião desenvolvedores PHP: php.net/~derick/...
Charles
7
POR QUE eles são tão ruins, por quê? Todo mundo é tão autoconfiante que é baaaaaad, mas ninguém diz o porquê.
1911 Josef Sábl
6
FALSO. Eles estão eliminando gradualmente as tags <%%>, como deveriam. Eles não servem a nada, a não ser confundir. O <? ?> tags não serão afetadas; mas é claro que eles ainda podem ser configurados por servidor e você deve sempre estar ciente dos requisitos da sua plataforma de destino.
Brian Lacy
6
Essa informação parece estar incorreta e enganosa e deve ser corrigida pelo autor.
tex