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

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?

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.

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.

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:

• Revisão SVN por Rasmus Lerdorf
• Discussão da lista de discussão

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

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.

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.

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

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

Fonte: pergunta semelhante sobre Software Engineering Stack Exchange

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.

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

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

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

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?

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

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.

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

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) ?> 

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

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

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.

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

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

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.

<?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;?>

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'

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>

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 .

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

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.