Posts da Tag: PSR - Blog da TreinaWeb

PHP

PSR-4 a recomendação de autoload do PHP

Na linguagem de programação PHP temos uma série de recomendações chamadas PSRs. Elas são definidas por um grupo de desenvolvedores em conjunto com a comunidade. Nesse post vamos falar de uma das PSRs, a PSR-4 que visa padronizar o modo como carregamos os arquivos na linguagem de programação PHP.

Caso não conheça o que é PHP-FIG, PSR, RFC e outros detalhes, aconselho leitura do artigo O que são as PSRs do PHP.

Porque criar uma padronização como a PSR-4 para autoload

Uma aplicação PHP por menor que seja precisa ser dividida em vários arquivos para manter a organização. Os arquivos consequentemente precisam ser incluídos para que o código dentro dele possa ser usado. Com esse intuito usamos o que chamamos em PHP de autoloading, que basicamente é uma lógica para carregar nossos arquivos automaticamente.

O problema é que cada projeto implementava uma lógica diferente para carregar os arquivos e também para estrutura de pastas onde esses arquivos eram colocados. E como já falamos no artigo sobre o que são PSRs, quando cada projeto ou empresa usa um padrão temos vários problemas. Além disso, nem sempre reinventar a roda é uma boa ideia quando falamos de programação, muitas vezes o modo como era feito não era o melhor.

Pensado em uma padronização única de carregamento o PHP-FIG criou a PSR-0 que com o tempo acabou sendo descontinuada e a PSR-4 passou a ser indicada em seu lugar.

Porque seguir a PSR-4

A PSR-4 vai de encontro ao desenvolvimento moderno de aplicações PHP e possui tudo que o desenvolvedor precisa para trabalhar com orientação a objetos. Ela foi pensada para funcionar com namespace e facilitar que o projeto atenda outras recomendações, como por exemplo a PSR-1.

O PSR-4 pode ser facilmente utilizado com autoload do composer, além de ser o padrão adotado pelos principais frameworks PHP do mercado, como:

Devido a maioria dos projetos atuais do mercado utilizarem PSR-4, quando um novo desenvolvedor entrar no projeto, provavelmente ele já conhecerá a recomendação e começará produzir mais rápido.

Namespace e estrutura de pastas na PSR-4

Se olharmos o namespace de uma classe e o caminho de um arquivo no sistema operacional vamos ver que eles são extremamente parecidos:

Por exemplo, no linux poderíamos ter o caminho de um arquivo assim: Treinaweb/Recursos/Curso.php e no PHP um namespace igual abaixo:

<?php

namespace Treinaweb\Recursos;

class Curso
{
    //...
}

A PSR-4 faz uso exatamente dessa característica em comum, desse modo precisamos definir o mínimo possível de lógica para carregar nossos arquivos, temos a vantagem da organização dos namespaces seguir o mesmo padrão que a dos arquivos, além de fazer uso da estrutura de diretórios do sistema operacional que é algo amplamente conhecido.

Recomendações para definição do namespace na PSR-4

Quando utilizamos a PSR-4 temos que seguir algumas recomendações na hora de definir o namespace em nossas classes. Ele deve seguir a estrutura abaixo:

<NomeNameSpace>(\<SubNamespaceNames>)*\<NomeClasse>
  • É necessário um namespace principal, que no exemplo acima é representado por <NomeNameSpace>. Ele também é conhecido por namespace do fornecedor (vendor namespace). Se estiver desenvolvendo um projeto que será compartilhado, por exemplo, uma biblioteca, é importante que o namespace principal seja unico;
  • Podemos ter quantos sub-namespaces forem necessários para organização da nossa aplicação, por exemplo: Treinaweb\Recursos\AVA\Cursos\Curso tem os sub-namespaces Recursos\AVA\Cursos
  • Sempre deve terminar com o nome de uma classe, no exemplo Treinaweb\Recursos\AVA\Cursos\Curso, Curso é o nome da nossa classe;
  • Os caracteres do caminho do namespace podem ter letras maiúsculas e minúsculas;
  • O nome da classe sempre deve ser referenciado em case-sensitive, ou seja, respeitando letras maiúsculas e minúsculas

Veja o exemplo de um controller em uma aplicação Laravel:

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class UserController extends Controller
{
    /**
     * Store a new user.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $name = $request->input('name');

        //
    }
}

No caso do namespace Illuminate\Http\Request que o código acima importa, temos:

  • Illuminate – É o namespace principal (vendor namespace);
  • Http – Sub-namespace de organização interna da aplicação;
  • Request – Nome da classe

Recomendação para carregamento dos arquivos na PSR-4

O carregamento dos arquivos acontecem de acordo com a estrutura do namespace que definimos. Para ele acontecer deve seguir os seguintes detalhes:

  • O namespace principal (vendor namespace) deve indicar para o diretório de base;
  • Os sub-namespaces definidos representam os diretórios criados dentro do diretório base. Seguindo o mesmo padrão de letras maiúsculas e minúsculas definidas em cada sub-namespace;
  • O nome da classe no namespace deve seguir o mesmo padrão do nome do arquivo onde a classe está. O arquivo deve terminar com .php e seguir mesmo padrão de maiúsculas e minúsculas do nome da classe.

Como funciona a PSR-4

Vamos pegar o exemplo do namespace Illuminate\Http\Request novamente. Se olharmos a estrutura de pastas do projeto veremos:

Definição nome de pasta e arquivos na PSR-4

  • Vendor namespace Illuminate aponta para a pasta src/Illuminate/;
  • Sub-namespace Http aponta para a pasta de mesmo nome;
  • Nome da Classe Request aponta para o arquivo Request.php

Como usar a PSR-4 no meu projeto

O modo mais fácil de usar o padrão PSR-4 em um projeto PHP através do próprio gerenciador de dependência Composer. No arquivo composer.json configuramos o vendor namespace e a pasta principal a partir de onde serão criados os sub-namespaces:

"autoload": {
   "psr-4": {
        "Treinaweb\\": "src/"
    },
 },

Então podemos criar uma classe conforme abaixo que ficaria dentro da pasta src/Recursos chamado Curso.php:

<?php

namespace Treinaweb\Recursos;

class Curso
{
    //...
}

O composer possui dentro da pasta vendor um arquivo chamado autoload.php basta carregar ele e então todas as classes que instanciar automaticamente serão carregadas seguindo a lógica que aprendemos da PSR-4:

<?php

require_once "vendor/autoload.php";

$request = new Treinaweb\Recursos\Curso();

Ao carregarmos o arquivo de autoload do composer automaticamente as classes das dependências instaladas no projeto também serão carregadas via autoload.

Também é possível implementar a lógica de carregamento da PSR-4 diretamente no seu projeto. No repositório oficial do PHP-FIG tem alguns exemplos de implementação da PSR-4.

Considerações finais sobre a PSR-4

A PSR-4 é o padrão mais utilizado da linguagem PHP. Ele vai de acordo com o desenvolvimento moderno PHP, é de amplo conhecimento da comunidade, além de ser facilmente usado com o composer o que permite iniciar o projeto sem ter que se preocupar em implementar autoload no projeto.


PHP

PSR-1 Conheça os padrões básicos de codificação do PHP

Neste artigo falaremos sobre a PSR-1 e a importância dela para o PHP. Ela foi uma das primeiras aceitas pelo PHP-FIG e fala sobre padrões básicos de codificação.

No artigo anterior falamos sobre o que é PSR, PHP-FIG e outros conceitos importantes para o pleno entendimento deste artigo. Aconselho dar uma olhadinha aqui: O que é PSR no PHP

Arquivos

As PSRs são divididas por tópicos. O primeiro tópico da PSR-1 fala sobre recomendações que devemos usar nos arquivos php da nossa aplicação.

Tags

Devemos usar somente as tags de abertura de código PHP <?php e <?=.

Essa recomendação existe, porque até a versão 7 o PHP permitia o uso de outras tags como <%, <%= e <script language=”php”>.

Charset Encode

Devemos configurar no editor o charset UFT-8 sem BOM.

No Visual Studio Code essa configuração já é definida por padrão:

Efeito Colateral

Recomendado que um arquivo contenha apenas declarações (classes, constantes, funções e outros) ou cause algum efeito colateral (saída com echo, includes, modificação de configurações, emissão de erros e outros), mas não é recomendado ambos em um único arquivo.

Um exemplo de arquivo apenas com declarações:

<?php

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

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

Um exemplo de arquivo apenas uma lógica que causa efeito:

<?php

// causa efeito colateral
ini_set('error_reporting', E_ALL);

// causa efeito colateral
include "file.php";

// causa efeito colateral
echo "<html>\n";

Agora um exemplo não recomendado misturando declarações com efeitos colaterais no mesmo arquivo:

<?php

// causa efeito colateral
ini_set('error_reporting', E_ALL);

// causa efeito colateral
include "file.php";

// causa efeito colateral
echo "<html>\n";

// faz uma declaração
function somar()
{
    // corpo da função
}

Namespace e nome de classe

Namespaces e classes devem seguir uma PSR de autoload.

Cada classe deve estar em um arquivo próprio e possuir ao menos um nível de namespace. O primeiro nível do namespace deve ser o nome do fornecedor, que pode ser o nome do projeto ou do desenvolvedor.

Classes devem ser declaradas usando StudlyCaps ou também conhecido como PascalCase. Padrão onde a letra inicial de cada palavra deve ser maiúscula.

A partir da versão 5.3 do PHP é obrigatório o uso de namespace.

<?php

namespace Fornecedor\Model;

class Produto
{
}

Em versões anteriores a 5.3 usávamos a identificação completa no nome da classe, por exemplo, Fornecedor_Model_Produto. A versão 5.3 foi lançada em 2009, então dificilmente encontramos projetos ainda com esse padrão de nome de classes e sem uso de namespace.

Constantes de classes, propriedades e métodos

Na PSR-1 ao se referir a classe também consideramos classes, interfaces e traits.

Constantes em classes

As constantes declaradas dentro de uma classe devem ter o nome em maiúsculo e separado por underlines:

<?php

namespace Fornecedor\Model;

class Produto
{
    const EMPRESA = 'Treinaweb';
    const TIPO_PRODUTO = 'Curso';
}

Propriedades

A PSR-1 não indica qual padrão deve ser utilizado no nome das propriedades. Ela apenas recomenda que o padrão escolhido no projeto seja seguido em todos os locais por uma questão de consistência

Na prática a maioria dos projetos hoje utiliza o padrão $camelCase com o nome da primeira palavra em minúsculo e das demais em maiúsculo. Veja por exemplo algumas propriedades da classe Request do Laravel Framework:

/**
* The decoded JSON content for the request.
*
* @var \Symfony\Component\HttpFoundation\ParameterBag|null
*/
protected $json;

/**
* All of the converted files for the request.
*
* @var array
*/
protected $convertedFiles;

/**
* The user resolver callback.
*
* @var \Closure
*/
protected $userResolver;

/**
* The route resolver callback.
*
* @var \Closure
*/
protected $routeResolver;

Nomes de métodos

Nomes de métodos devem sempre serem declarados camelCase. Isso é um dos motivos para o uso desse padrão também em nome de propriedades na maioria dos projetos, conforme vimos no tópico anterior.

Considerações finais

A PSR-1 possui recomendações que parecem até bobas a primeira vista, pois hoje a maioria dos desenvolvedores PHP já seguem ela mesmo sem saber, porém ela é de grande importância. Além de definir elementos básicos do código PHP ela também é usada como requisito para PSR-12, se seu código não segue a PSR-1 não terá como seguir a PSR-12.

Inclusive vamos falar sobre a PSR-12 em nosso próximo post. Fique ligado em nosso blog e também nas redes sociais.


PHP

O que são as PSRs do PHP

A linguagem de programação PHP, assim como outras linguagens, permite que os desenvolvedores escrevam código de diversas maneiras possíveis. Essa característica é até interessante, pois garante mais liberdade para os desenvolvedores, porém isso também pode ser um problema.

A diferença no modo como os desenvolvedores escrevem código pode gerar uma verdadeira salada de frutas dependendo do tamanho da equipe e quantas pessoas já passaram no projeto ao longo do tempo.

Baseado nisso muitas linguagens e tecnologias definem recomendação de padrões. No PHP essas recomendações são criadas por um grupo chamado PHP-FIG e são chamadas de PSR.

WordPress - Criação de Plugins
Curso de WordPress - Criação de Plugins
CONHEÇA O CURSO

PHP-FIG

PHP Framework Interop Group (PHP-FIG) é um grupo formado por desenvolvedores da comunidade PHP em 2009. O objetivo inicial do grupo era definir recomendações que fossem aplicadas aos Frameworks PHP participantes e facilitasse a interoperabilidade entre os frameworks que cresciam rapidamente.

Ao passar do tempo o grupo começou a perceber que as recomendações poderiam ser úteis em outros tipos de aplicações, não somente em frameworks, já que a linguagem PHP possui grandes CMSs como WordPress, Magento, Drupal, Joomla e diversos outros. Com isso o grupo ganhou membros também de outros tipos de projetos, não somente Frameworks.

As recomendações precisam ser votadas e aprovada pelos membros do PHP-FIG para que possam ter validade. Somente membros podem votar, porém qualquer desenvolvedor da comunidade que queira participar das discussões pode, basta entrar nos canais de contato do PHP-FIG.

PSR

As recomendações criadas pelo PHP-FIG são agrupadas em PHP Standard Recommendation (PSR). Uma PSR basicamente possui recomendações sobre um tema específico, como por exemplo, a PSR-12 que fala sobre padronização de sintaxe de código.

Cada PSR é identificada por um número e possui um status. O status nos ajuda a saber se devemos ou não seguir as recomendações daquela PSR:

  • Rascunho – enquanto uma PSR está em discussão e construção ela é definida como rascunho;
  • Aceito – quando uma PSR é votada e aprovada o status dela passa para aceita;
  • Descontinuada – se por algum motivo depois de aceita aquela PSR não é mais relevante ela é descontinuada;
  • Abandonada – quando o rascunho de uma PSR não é aceito, ela passa para o estado abandonada e é mantida por questão de documentação.

Existem PSRs que tratam de diversos temas como: estilo de código, autoload, cache, log, HTTP e outros. É possível ver a lista de PSRs e seus estados no site do PHP-FIG.

RFC

Assim como o PHP-FIG se propôs a discutir recomendação de padrões para a linguagem PHP, existem outros grupos que definem recomendações para diversos tipos de processos que acontece na internet. Esses grupos criam documentos técnicos chamados de Request For Comments (RFC), em português requisição para comentários. As RFCs possuem um funcionamento muito parecido com as PSRs, inclusive o processo de criação das PSRs é inspirado no processo de criação das RFCs.

As PSRs usam RFCs dentro de suas recomendações. Elas são usadas tanto como base para padronização de alguma recomendação, quanto para orientar o requerimento de uma recomendação.

Nível de requerimento

A RFC mais importante para conseguirmos interpretar corretamente as recomendações das PSRs é a RFC 2119. Ela padroniza os níveis de requerimento de uma determinada recomendação.

Podemos dividir os níveis de requerimentos em:

  • Deve – representado pelas palavras (MUST, REQUIRED e SHALL)
  • Não deve – representado pelas palavras (MUST NOT e SHALL NOT)
  • Recomendado – representado pelas palavras (SHOULD e RECOMMENDED)
  • Não recomendado – representado pelas palavras (SHOULD NOT e NOT RECOMMENDED)
  • Opcional – representado pelas palavras (MAY e OPTIONAL)

Vamos pegar um exemplo prático para entender o nível de requerimento. A PSR-1 que fala sobre padrão básico de codificação tem a seguinte recomendação:

Files MUST use only <?php and <?= tags.

Em português ficaria: arquivos DEVEM usar somente as tags &lt;?php e &lt;?=.

O nível de requerimento é representado por uma das palavras listadas na RFC2119, ele nos ajuda a entender quando devemos ou não seguir uma recomendação dentro de uma PSR. No exemplo acima nós DEVEMOS usar somente essas duas tags se quisermos dizer que nosso código segue a PSR-1.

PSR-1 e PSR-12

As duas primeiras PSRs que aconselho estudar são: a PSR-1 e a PSR-12. A primeira fala sobre padronização básica do nosso código e a segunda fala sobre o estilo como o código é escrito. A PSR-12 substituiu e estendeu a PSR-2, que precisou ser revisada devido a avanços na linguagem de programação PHP.

Nos próximos artigos vamos falar sobre essas duas importantes PSRs. Fique atento em nosso blog e redes sociais.

Formação:
CONHEÇA A FORMAÇÃO