Omitir ponto e vírgula em uma tag - uma boa ideia?


8

É possível omitir o ponto e vírgula final em uma tag.

Exemplo:

<table>
  <th><td>Name</td><td>Email</td>
  <? foreach ($receivers as $receiver): ?>
  <tr>
    <td><?= $receiver->name ?></td>
    <td><?= $recevier->email ?></td>
  </tr>
  <? endforeach ?>
</table>

Observe o <? endforeach ?>sem ponto e vírgula depois endforeach. A documentação do PHP diz:

A tag de fechamento de um bloco de código PHP implica automaticamente um ponto e vírgula; você não precisa ter um ponto e vírgula finalizando a última linha de um bloco PHP.

Por que estou abordando esse assunto?

Atualmente eu e um amigo meu trabalhamos em um projeto PHP proprietário com MVC (model-view-controller). Para a visualização, avaliei alguns mecanismos de modelo PHP como Smarty, Bigode e até projetei meu próprio mecanismo de modelo doméstico. Mas quando eu li que o PHP é um mecanismo de modelo em si, algo foi " clique " na minha cabeça. Por que não concordar com a equipe em usar um subconjunto limitado do PHP como um mecanismo de modelo? E tendo muitas revisões de código para manter as regras?

E esse subconjunto pode ficar assim:

  • Use tags apenas de curto <?, <?=e?>
  • Use apenas expressões simples sem efeitos colaterais, especialmente não atribua variáveis
  • Use apenas if, foreache includepara as demonstrações
  • Use apenas a sintaxe alternativa para estruturas de controle
  • Tenha apenas uma instrução em uma tag cada

Este é o contexto em que estamos omitindo o ponto e vírgula final, ou seja <? endforeach ?>, para <? endif ?>e <? include("list-contents.php") ?>.

No entanto, eu sempre leio que omitir o ponto e vírgula é uma má prática. Por quê? É uma má prática?

Estou feliz que o PHP permita omitir o ponto-e-vírgula final, pois isso minimiza a confusão visual nos arquivos de modelo. Eles devem se parecer principalmente com arquivos HTML com apenas pequenos fragmentos de PHP aqui e ali. O exemplo acima é o que estou buscando.

O que você pensa sobre isso? Se você é contra: por quê? Se você apoia: Por que seria uma boa ideia? O que devo dizer ao meu parceiro se ele está me referindo algum texto contra a omissão do ponto e vírgula?

Faça backup de sua opinião com fatos, referências ou sua própria experiência.

Respostas:


1

Eu acho que é uma boa idéia usar PHP, ou pelo menos um subconjunto de, como uma linguagem de modelo. Será mais fácil a integração de novos desenvolvedores com seu sistema, pois não há sintaxe de biblioteca especial para aprender e você não tem a sobrecarga dessa biblioteca que analisa seu modelo apenas para transformá-lo em PHP.

Além disso, você perdeu um contexto no qual precisaria eliminar o ponto-e-vírgula final em suas instruções de eco variável, por exemplo <?= $receiver->name ?>. Se você não usar ponto-e-vírgula em seus modelos, precisará realmente não usá-los. Claramente, seu exemplo de código não os utiliza, mas eu só queria apontar o contexto ausente no qual não usar ponto e vírgula final.

O mais importante é ter a adesão da equipe e garantir a consistência entre seus modelos. Pessoalmente, acho chocante não ter ponto e vírgula ... Instintivamente, quero adicionar esses pontos e vírgulas em todas as suas instruções PHP. Você tem uma pessoa em sua equipe com o mesmo nível de TOC? Como eles vão reagir a isso? Se sua equipe não tem adesão e uma ou duas pessoas são veementemente contra ela, faça-as defenderem sua decisão, talvez esse não seja o melhor caminho a seguir.

Outra armadilha potencial seria incorporar novos membros da equipe. Eles podem muito bem não perceber que você pode fazer isso, voltar nos seus modelos e inserir todos os pontos e vírgulas finais, quando apropriado. Obviamente, este é um caso de um desenvolvedor que não conhece tanto o PHP quanto deveria, mas é algo que você gostaria de considerar na sua decisão. Educar novos desenvolvedores juniores que, nos modelos, não usamos ponto-e-vírgula final, mas outro código que fazemos.

tl; dr

Obtenha adesão de sua equipe, garanta que seus modelos sejam consistentes e tenha um plano razoável para educar os novos desenvolvedores sobre como o código PHP nos modelos difere do código PHP "normal" (sintaxe alternativa, sem ponto e vírgula final, estruturas PHP permitidas etc.) )


2

Sou a favor de omiti-los nesse caso, e faço exatamente isso, especificamente porque nesse contexto eu só uso uma instrução de linha única por bloco ou. Reduz a desordem visual e, em todos os meus anos de atuação, nunca resultou em um único problema.


0

Use apenas tags curtas

Não. Por favor, Deus não! Confiar em tags abertas curtas é uma péssima idéia. Isso apenas torna seu código menos portátil. Tags abertas curtas não são ativadas por padrão em muitos sistemas. E se você quiser compartilhar o código com alguém que os desativou? Além disso, nada é ganho a partir de pequenas etiquetas abertas IMHO.

Use apenas a sintaxe alternativa para estruturas de controle

Não vejo o que você ganharia com isso. Além de não ter uma base de código consistente.

Tenha apenas uma instrução em uma tag cada

Isso também pode tornar as coisas confusas. Quando você tem algum "modelo" cheio de tags de abrir / fechar em todos os lugares.

Por que não concordar com a equipe em usar um subconjunto limitado do PHP como um mecanismo de modelo?

Isso depende de quem está nessa equipe. Por exemplo, somente as pessoas o usarão que conhecem PHP? Ou você também tem pessoas nessa equipe que precisam alterar os modelos que não conhecem o PHP. Se for o primeiro, eu simplesmente relaxarei nos requisitos (regras), porque quando as pessoas enfrentam um problema, elas podem facilmente resolver com todo o poder que o PHP fornece e você as limita a resolvê-lo. regras ou obter um código muito confuso. No entanto, se você tem pessoas na equipe que não conhecem PHP, você pode se safar dessa maneira.

Agora, para responder à sua pergunta:

No entanto, eu sempre leio que omitir o ponto e vírgula é uma má prática. Por quê? É uma má prática?

Ao codificar (independentemente do idioma e do projeto), você sempre deve reduzir o número de wtf's por minuto no seu código. Portanto, é uma prática ruim porque, quando alguém olha para aquilo, pode pensar a princípio: ei, aí está algo estranho! É apenas que as pessoas PHP são usadas para que haja ponto-e-vírgula para fechar instruções. Então, novamente, isso pode depender das pessoas da sua equipe (mas você perguntou por experiência pessoal). Além disso, também é muito irritante alternar entre sintaxes quando as pessoas estão trabalhando no front-end (os modelos) e no back-end. E é propenso a erros e aborrecimentos na equipe.

E, finalmente, sobre o fato de o PHP permitir que você faça algo: o PHP permite que você faça todo tipo de coisa. Apenas esse fato não significa que você deve usá-lo. Houve uma meta post uma vez no Stack Overflow que sobre o Stack Overflow não é o exemplo perfeito de suas próprias regras (ou algo parecido com isso :)) que também pode ser usado para PHP. Há todo tipo de material FUBAR no PHP (sim, eu já disse), mas isso não deve significar que você deva dizer: mas, mas o PHP permite. Adivinha o que o PHP também permite que você execute consultas sem entrada de saneamento. O PHP também permite escrever todo o código em uma única linha. O PHP também permite que você crie nomes de variáveis ​​como $S0mEvAriBLe. Todas essas coisas não significam que é a melhor coisa a fazer.

Meus 2 centavos


Deixe-me comentar seus pontos: 1) Sintaxe alternativa porque o modelo HTML é um domínio diferente do "PHP normal". Eu quero enfatizar isso com diferentes construções. 2) Apenas uma instrução em uma tag, porque as visualizações são principalmente HTML com apenas um pouco de código PHP. 3) Limitar o poder do PHP por causa da separação de preocupações. Nas visualizações, nada sobre o aplicativo é decidido, calculado ou consultado. É a tarefa do controlador junto com o modelo. Isso atrapalharia a separação se alguém usasse todo o poder do PHP em uma exibição. Obrigado pela sua resposta. Isso é útil.
nalply
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.