Se você desenvolvedor PHP há algum tempo, certamente já teve contato com projetos escritos em todo e qualquer tipo de estrutura: alguns bons, alguns nem tanto, outros… impossíveis de se compreender. Isso faz com que os desenvolvedores percam muito do seu precioso tempo tentando decodificar a mente maquiavélica do(s) autor(es) do projeto em questão. Mas e se existisse uma série de regras globais para todos os projetos PHP seguirem, a fim de se obter uma estrutura padrão de diretórios, carregamento automático de classes e até da formatação do código?

Bom, existe. E quem cuida disso é o PHP-FIG (Framework Interop Group).

“A ideia deste grupo é que representantes de projetos possam conversar sobre pontos em comum entre seus projetos e encontrar formas de trabalharmos juntos. Nosso público alvo somos nós mesmos, mas sabemos que a comunidade PHP está participando. Qualquer pessoa que queira adotar o que estamos fazendo é bem-vinda, mas este não é o nosso foco.”

Em outras palavras: o FIG é um grupo composto por representantes de grandes projetos em PHP, tais como como o CakePHP, Doctrine, Symfony 2, Drupal e Zend Framework 2. Este grupo busca criar padrões que todos esses projetos possam seguir, definindo assim um “formato global” para projetos PHP. Esses padrões são criados com foco nos projetos participantes, mas podem ser facilmente implementados em qualquer projeto que precisemos desenvolver. E o que ganhamos com isso é a manutenibilidade, ou seja, a facilidade que teremos para realizar processos de manutenção nesses projetos.

Esses padrões são chamados de PSR - PHP Standard Recommendation (ou padrão recomendado para PHP, em tradução livre), e cada um deles especifica um conjunto de regras diferentes, entretanto, eles podem ser utilizados em conjunto, uma vez que cada conjunto de regras define uma prática específica.

Até a data desta publicação, existem 4 PSR ativas (PSR-1, PSR-2, PSR-3 e PSR-4) e 1 PSR obsoleta (PSR-0, substituída pela PSR-4). Existem também as PSR-5, PSR-7, PSR-8 e PSR-9, que ainda estão em desenvolvimento, e a PSR-6, que está em fase de revisão, e você pode conferir todo o conteúdo, com exemplos no site oficial: php-fig.org.

Nesta série de artigos, vamos conhecer cada uma das PSR disponíveis e entender o impacto delas em nossos projetos.

Vamos começar com a PSR-1 (falaremos sobre o PSR-0 juntamente com o PSR-4), que define um padrão de codificação para os projetos PHP.

As PSR definem elementos usando algumas chaves para identificar sua aplicação no projeto. Essas chaves são:

“MUST” (DEVE);
“MUST NOT” (NÃO DEVE);
“REQUIRED” (OBRIGATÓRIO);
“SHALL” (TEM QUE);
“SHALL NOT” (NÃO TEM QUE);
“SHOULD” (DEVERIA);
“SHOULD NOT” (NÃO DEVERIA);
“RECOMMENDED” (RECOMENDADO);
“MAY” (PODE);
“OPTIONAL” (OPCIONAL).

Mas o que são esses “elementos” definidos por essas chaves? Veja um resumo abaixo:

Isto é, as short open tags (<?), tags ASP (<%) e as tags de script (<script language="PHP">) não devem, jamais ser utilizadas, isto porque, em alguns ambientes, essas tags de abertura podem estar desabilitadas e, se ativadas, podem causar problemas com outros arquivos do projeto em questão.

Obs. vale ressaltar que, desde o PHP 5.4, independente do uso de short open tags (<?) o PHP permite a utilização de <?=, que equivale a <?php echo.

Arquivos PHP DEVEM usar somente a codificação UTF-8 sem BOM (Byte Order Mark)
Nada de utilizar UTF-8 com BOM, ISO-8859-1 e nenhum outro tipo de codificação. o UTF-8 sem BOM é a codificação padrão, e a maioria dos editores já vêm configurado desta forma, logo, se você cria um arquivo em ISO-8859-1, quando este arquivo for editado, muito provavelmente o desenvolvedor que estiver trabalhando com este arquivo terá problemas.

Arquivos PHP DEVERIAM ou declarar símbolos (classes, funções, constantes, etc.) ou causar efeitos colaterais (gerar output, modificar configurações no php.ini, etc.). Mas NÃO DEVERIAM fazer ambos
Essa regra visa evitar aqueles arquivos de classe que também executam algo caso acessados diretamente, ou a clássica index.php com um monte de classes definidas antes de se exibir o conteúdo. Se você tem um arquivo de classe, defina apenas a classe, seus métodos, variáveis e constantes. Se tem um arquivo que gera output (exibe conteúdo na tela), faça  com que ele apenas gere o output.

Namespaces e classes DEVEM seguir o PSR-0
Logo vamos chegar lá, mas, em resumo, os nomes das classes (e seus namespaces) devem seguir um padrão de diretórios para possibilitar a geração de um autoloading eficaz.

Nomes de classes DEVEM ser decaradas em StudlyCaps
Simples: todas as palavras das classes devem possuir a primeira letra maiúscula, ou seja: minhaClasse está errado, enquanto MinhaClasse está certo. Se sua classe é definida por apenas uma palavra, a regra também vale: o correto é utilizar, por exemplo, Compras, e não compras.

Constantes DEVEM ser declaradas totalmente com letras maiúsculas e separadas por underscores
Se você precisa definir uma constante, defina-a com letras maiúsculas, e se for um nome composto, use underscore (_) para separar as palavras, por exemplo: minhaConstante está errado, enquanto MINHA_CONSTANTE está certo.

Nomes de métodos DEVEM ser declarados em camelCase
Quando for definir o nome de um metódo, a primeira palavra sempre precisa iniciar com letra minúscula, e as palavras subsequentes iniciam com letra maiúscula, ou seja:

public function Metodo(){} está errado, o correto seria public function metodo(){}, assim como public function Meu_Metodo(){} está errado e deve ser substituído por public function meuMetodo().

Vale lembrar que quando dizemos que certa definição é “errada”, não quer dizer que não vá funcionar. Quando falamos de PSR, falamos a partir de um ponto em que o código já funciona, e as regras definidas na PSR em questão são apenas um “guia” para que possamos criar códigos padronizados e que causem menos dor de cabeça futuramente.

Essa foi a explicação da PSR-1, nos próximos artigos falaremos sobre a PSR-2, PSR-3,  PSR-0 sua substituta PSR-4, e depois um review sobre as PSR que poderão surgir em breve.

Se ficou com qualquer dúvida ou gostaria de acrescentar qualquer informação, sinta-se a vontade para comentar abaixo.

Até a próxima!