Padrão PSR-1 de desenvolvimento PHP – O mínimo para uma boa comunicação entre códigos PHP diferentes Artigo

Conheça os cursos gratuitos do WebDevBr! - Inscreva-se!


Este artigo foi publicado a 4 anos, 2 meses, 1 semana atrás.

Bem, continuando  com o artigo anterior, quando apresentei as PSRs e falei sobre a PSR-0, agora vou falar um pouco sobre a PSR-1 que seta o mínimo que se deve fazer para desenvolver algo que tenha uma boa interoperabilidade técnica entre códigos PHP, traduzindo, que se comunique bem com outros códigos PHP.

As regras são bem simples de se seguir, basta entendê-las.

Aqui um link para o repositório em pt-br da PSR-1.

Gostou deste artigo?

Receba atualizações semanais com novos artigos do WebDevBr e outras dicas!

E aqui em inglês.

Os arquivos DEVEM usar apenas tags <?php e <?=

Essa é bem simples, todo arquivo deve informar o bloco de códigos PHP com para dizer que está terminando. Pro assunto não ficar curto demais vou adiantar as coisas e já falar sobre um tópico da PSR-2 que fala sobre arquivos somente PHP, neste caso deve-se omitir a tag PHP de fechamento (?>) isso nos ajuda a evitar que qualquer coisa seja impressa em local indevido, por exemplo o header() que não pode ser usado após qualquer coisa que não seja PHP, exemplo:

Exemplo.php (arquivo de classe php, não contém qualquer outra coisa).

<?php
class Exemplo
{
  //conteúdo
}

Os arquivos DEVEM usar apenas UTF-8 sem BOM para código PHP

Isso aqui confundi um pouco no começo, já que a palavra BOM tem significado no português, acredito que na tradução deveria vir acompanhada do termo por extenso e não somente a sigla, assim: Os arquivos DEVEM usar apenas UTF-8 sem Byte Order Mark (BOM) para código PHP.

Bem para quem não sabe, BOM é uma assinatura que é colocada no começo de arquivos UTF, ele faz muito sentido nos padrões UTF-16 e UTF-32 dizendo como o user agent deve interpretar o conteúdo, mas no caso no UTF-8 não faz sentido, isso gera alguns caracteres no começo do arquivo que não são mostrados na maioria das aplicações de desenvolvimento, e nas que mostra, acaba exibindo uma linha em branco, um espaço ou mesmo um alguns caracteres "aparentemente sem sentido" logo no início do arquivo, eu mesmo tive problemas com isso recentemente no NetBeans.

Alguém aqui conhece o Bloco de Notas do Windows? Pois é, ele acrescenta isso, só pra vocês tomarem nota.

Quer testar se uma página está com BOM ou sem ele? Use isso:

http://people.w3.org/rishida/utils/bomtester/index.php

Como fazer para remover?

Ai é uma novela, né! Existem milhares de possibilidades, posta no comentário a solução pro seu Editor/IDE.

Os arquivos DEVERIAM ou declarar símbolos (classes, funções, contantes, etc.) ou causar outros efeitos (ex: gerar output, alterar configurações .ini, etc.), mas NÃO DEVERIAM fazer ambas

Para desenvolvedores que trabalham segundo as PSRs existem dois tipos de arquivos, arquivos de declaração e os que fazem outras coisas (side-effects, efeitos colaterais na tradução direta ou efeitos secundários na documentação traduzida pelo Enrico Pereira), esta regra especifica exatamente que declarações devem ficar separados dos outros tipos de recursos, levando em conta que declarações entende-se por classes, funções, constantes... e o resto seria a parte de lógica, uso explícito de require e include, geração de saídas (html por exemplo),  modificações ini, modificação de variáveis globais e por ai vai, abaixo dois exemplos tirados da própria documentação:

Isso deve ser evitado:

<?php
// efeito secundário: mudança nas configurações ini
ini_set('error_reporting', E_ALL);

// efeito secundário: carregamento de arquivo
include "file.php";

// efeito secundário: geração de output
echo "n";

// declaração
function foo()
{
    // corpo da função
}

Isso seria correto:

<?php
// declaração
function foo()
{
    // corpo da função
}

// declaração condicional *não é* um efeito secundário
if (! function_exists('bar')) {
    function bar()
    {
        // corpo da função
    }
}

Parece complicado mas é bem simples na verdade.

Os namespaces e as classes DEVEM seguir a PSR-0.

Bem, seguindo a hierarquia das PSRs, quando você decide usar um padrão, todos os outros anteriores automaticamente precisam ser usados também, você pode por exemplo, decidir não usar  a PSR-2 e ficar só com a PSR-1, mas terá que usar a PSR-0 querendo ou não, agora se decidir usar a PSR-0 a PSR-1 não é obrigatória, com isso em mente, volte aqui e aprenda a PSR-0.

Os nomes de classe DEVEM ser declarados em StudlyCaps.

Aqui tem uma discussão bem legal por conta do que está escrito aqui: http://en.wikipedia.org/wiki/StudlyCaps. A página da Wikipedia diz que "StudlyCaps é uma forma de notação de texto em que a capitalização das letras varia de acordo com algum padrão, ou arbitrária, geralmente omitindo também espaços entre as palavras e muitas vezes omitindo algumas letras." (tradução livre do começo do texto), eu aceito que StudlyCaps é um padrão parecido com o UpperCamelCase, porém separado co underline ("_"), isso porque é o padrão usado pelo ZendFramework que é um membro com voto válido para a definição das regras PSR.

Então a classe Zend_PDF é inválida, e Zend_Pdf é válida, ok!

As constantes de classes DEVEM ser inteiramente declaradas em letras maiúsculas (upper case) separadas por underscores.

Ta, não precisa dizer muito, DIRECTORY_SEPARATOR já explica simples.

Os nomes de métodos DEVEM ser declarados em camelCase.

camelCase é o padrão de escrita em que se omite todos os espaços e são usadas letras maiúsculas para cada palavra, neste caso vamos usar a lowerCamelCase, exemplo:

function erikFigueiredo(){
    /* ... */
}
function erikProgramadorDesigner(){
    /* ... */
}

Conclusão

Pode parecer chato, arbitrário e até mesmo contra mão largar a forma que você gosta de desenvolver e começar a usar este padrão, mas entenda que é por um bem maior, depois que você se acostumar vai ter a certeza que sempre que pegar um código que segue os padrões, em outras palavras, de alguém que se preocupa com qualidade, vai facilitar o entendimento do que está escrito ali, e melhor, vais e muito mais fácil de você desenvolver o que precisa sem se preocupar com o framework PHP que está usando, use o que quiser de onde quiser e pronto, é só se organizar.

Até o próximo artigo, quando vamos falar da PSR-2.


Cursos relacionados


* Parcelamento apenas cartão de crédito! Pode haver uma pequena variação no parcelamento em relação a simulações apresentadas!