Forem: Arthur Barboza

Cronjob

Arthur Barboza — Tue, 24 Jun 2025 02:06:58 +0000

Atualmente muitos sistemas comerciais fazem uso de funcionalidades e recursos de forma repetitiva, até mesmo com alguns recursos que passam a se tornar procedimentos rotineiros e comuns.

A Cron é uma ferramenta presente em vários sistemas e permite realizar o agendamento de tarefas (cronjob) e execução de scripts de forma automática.

A mesma pode ser utilizada para processamento de informações em lote, pois também pode ser executada de forma assíncrona.

Presente até mesmo em sistemas operacionais Unix, o formato "cron" serve para descrever o intervalo em que determinada cronjob deve ser executada podendo ser descrito conforme imagem abaixo

O registro de tarefas é feito através da Crontab, um deamon do sistema operacional que possibilita a criação e agendamento de tarefas.

Tarefas agendadas serão executadas a menos que ocorra algum imprevisto, como por exemplo uma outra tarefa estava em execução naquele momento, sendo então necessário que a tarefa não executada seja reconfigurada na Cron a fim de executar a tarefa em outro momento.

Filas e Mensagens Assíncronas

Arthur Barboza — Tue, 24 Jun 2025 00:52:31 +0000

Introdução

Um dos maiores progressos no desenvolvimento de software moderno, se trata da utilização de fila no processamento assíncrono de informação. Softwares modernos que fazem uso de dados em grande quantidade ou mesmo informações que não se encontram disponíveis naquele instante, são cenários os quais a implementação de uma fila de mensagens assíncronas é o ideal.

Fila na Estrutura de Dados

A fila é uma estrutura de dados tradicional e bem conhecida tanto na literatura acadêmica quanto no mercado de trabalho, sendo utilizada em inúmeras aplicações. Alguns exemplos são sistemas para registro de pedidos, gerenciadores de tarefas do sistema operacional, sistemas de registro de entrada de trabalho, entre outros.

A fila consiste em uma estrutura a qual uma sequência de elementos é processada de forma que cada elemento adicionado, entrará no final da sequência, após todos os elementos anteriores, este será processado antes dos elementos seguintes. Os elementos seguem uma ordem clara e preditiva, como uma fila para entrada de um cinema.

A Fila também pode ser descrita como uma estrutura First In First Out (FIFO), resumindo o comportamento sequencial dos seus elementos.

Na fila da imagem acima, o elemento 1 é adicionado anteriormente ao elemento 2, e justamente por isso ele é processado e removido antes do elemento 2.

Uma estrutura de fila apresentará essencialmente as seguintes operações (podendo ser adicionado outras conforme a necessidade do sistema) :

Enqueue : Adicionar o elemento que se encontrará no final da fila
Dequeue : Remover o elemento que se encontra no começo da fila
isEmpty : Verifica se a fila está vazia
Peek : Obtém o último valor da fila sem removê-lo.

As informações dos elementos serão tratadas e controladas através dos índices "FRONT" e "REAR", representando respectivamente a posição do elemento no começo da fila e a posição do elemento no final da fila.

Exemplo de implementação de fila :

<?php

class Queue {
    private $items = [];
    private $front = 0;
    private $rear = -1;

    public function enqueue($item) {
        $this->rear++;
        $this->items[$this->rear] = $item;
    }

    public function dequeue() {
        if ($this->isEmpty()) {
            throw new UnderflowException("Queue is empty. Cannot dequeue.");
        }

        $item = $this->items[$this->front];
        unset($this->items[$this->front]);
        $this->front++;

        // Optional: compact the array when queue is empty
        if ($this->isEmpty()) {
            $this->resetPointers();
        }

        return $item;
    }

    public function peek() {
        if ($this->isEmpty()) {
            throw new UnderflowException("Queue is empty.");
        }

        return $this->items[$this->front];
    }

    public function isEmpty() {
        return $this->front > $this->rear;
    }

    public function size() {
        return $this->rear - $this->front + 1;
    }

    // Reset pointers when queue becomes empty
    private function resetPointers() {
        $this->items = [];
        $this->front = 0;
        $this->rear = -1;
    }


    public function display() {
        return array_slice($this->items, $this->front, $this->size());
    }
}

// Example usage:
$q = new Queue();
$q->enqueue("Apple");
$q->enqueue("Banana");
$q->enqueue("Cherry");

echo "Front item: " . $q->peek() . PHP_EOL;
echo "Dequeued: " . $q->dequeue() . PHP_EOL;
echo "New front: " . $q->peek() . PHP_EOL;
print_r($q->display());

A complexidade da implementação de uma fila pode aumentar conforme a regra de negócio, sendo necessário implementar também uma de suas variações.

Algumas são :

Fila Circular
Fila de Prioridade
Fila Duplamente Terminada

Em aplicações reais, estruturas de fila são utilizadas através de "consumidores" e "publicadores", os quais são classes ou mesmo estruturas desenvolvidas conforme necessidade da aplicação que estará se comunicando com a fila.

As publicadoras se tratam de componentes que irão enviar para a fila algum elemento ou informação para ser processado, enquanto as consumidoras são componentes que irão consumir os dados após seu processamento, removendo os mesmos da fila.

Este processo ocorre de forma assíncrona, permitindo que as publicadoras e consumidoras sejam independentes, sem ocorrer uma comunicação direta e sem haver a necessidade de ambas estarem disponíveis no mesmo instante.

Por este motivo, é comum que as filas sejam implementadas de forma assíncrona para permitir o processamento de grande quantidade de dados ou até mesmo processamento de informações envolvendo a integração com sistemas externos.

Exemplos : envio de e-mail, gerar relatórios, exportar dados do banco e muitas outras situações.

Nesses casos é comumente utilizado softwares específicos para a implementação destes componentes, denominados mensageria.
Alguns exemplos são RabbitMQ, Kafka e muitos outros.

SOLID - Guia Completo

Arthur Barboza — Tue, 17 Jun 2025 03:06:45 +0000

SOLID é um acrônimo para descrever alguns dos princípios apresentados por Robert C Martin (também conhecido como Uncle Bob) para sistemas desenvolvidos através do paradigma orientado a objetos (POO).

Tais princípios formam a base para um código bem estruturado, o qual permitiria uma manutenção mais fácil e facilitaria o desenvolvimento de novas funcionalidades e sua refatoração.

Estes princípios buscam apresentar como um desenvolvedor pode tirar um bom proveito dos recursos do POO, evitando o aumento da complexidade do sistema e promovendo a reusabilidade do código.

Single Responsability Principal

O Princípio da Responsabilidade Única consiste em atribuir apenas uma responsabilidade para uma classe, promovendo maior segmentação do sistema e facilidade para identificar a localização de determinado trecho de código. Além do mais, concentrar muito código em uma classe resulta em um código extremamente acoplado e dependente, dificultando a manutenção e aumentando a possibilidade de introduzir bugs.

Tal cenário também dificulta o planejamento e desenvolvimento de testes para o sistema.

Um software que não está de acordo com este princípio, apresenta em seu código fonte uma ou mais "God Classes", a qual se trata de um anti-pattern que descreve uma classe com inúmeras responsabilidades.

Open-Closed Principle

O Princípio Aberto-Fechado consiste em descrever um código que esteja Aberto para extensões e fechado para alterações. Em outras palavras, para o desenvolvimento de novas funcionalidades, devemos sempre incrementar através de novas classes, e não alterar as superclasses.

Isso implica em um software com um nível de abstração bem estruturado e capaz de utilizar de forma eficiente os recursos de OOP tais como : herança, interfaces, polimorfismo e encapsulamento.

Exemplo :


// Classe original alterada. Não segue o princípio

// Antes
class Empregado {

    private $salario;

    public function calcularSalario()
    {
        return $this->salario;
    }
}

// Depois
class Empregado {

    private $salario;

    private $comissao;

    public function calcularSalario($vendas)
    {
        return $this->salario + ($this->comissao * $vendas);
    }
}


// Classe original preservada e extendida, está seguindo o princípio

class Empregado {

    protected $salario;

    public function calcularSalario()
    {
        return $this->salario;
    }
}

class EmpregadoComissionado extends Empregado {

    private $comissao;

    public function calcularSalarioComComissao($vendas)
    {
        return parent::calcularSalario() + ($this->comissao * $vendas);
    }

    // Neste caso, além de facilitar a manutenção, o método original está sendo preservado e não sofre alterações diretas 

}

Liskov Substitution Principle

O princípio da substituição de Liskov, implica que uma classe A a qual possui como subclasse a classe B, pode ser "substituída" pela classe B. Em outras palavras : uma subclasse deve ser compatível com os casos de uso da superclasse.

Exemplo :


class Empregado {

    protected $salario;

    protected $vendas;

    public function calcularSalario()
    {
        return $this->salario;
    }
}

class EmpregadoComissionado extends Empregado {

    private $comissao = 0.1;

    public function calcularSalario()
    {
        return parent::calcularSalario() + ($this->comissao * $this->vendas);
    }
}

function getEmpregadoSalario(Empregado $empregado){
    return $empregado->calcularSalario();
}


$empregado = new Empregado();
$empregadoComissionado = new EmpregadoComissionado();

echo getEmpregadoSalario($empregado);
echo getEmpregadoSalario($empregadoComissionado);

Nesse caso acima, a classe EmpregadoComissionado herda de Empregado, e o uso de Empregado pode ser substituído por EmpregadoComissionado.

O princípio implica em inúmeros fatores, tais como visibilidade e assinatura de métodos, lançamento e tratativa de exceções, retornar valores de tipos diferentes de dados. Todos estes devem ser tratados para que o desenvolvedor garanta a conformidade com o princípio.

Este princípio garante a integridade do sistema e diminuí a possibilidade de surgir novos bugs inesperados.

Interface Segregation Principle

O Princípio da Segregação de Interface implica que uma classe não deve implementar uma interface a qual apresenta métodos que não serão utilizados.

Diferente do que por vezes ocorre, implementar uma interface e apenas apresentar a assinatura seguido pelo corpo vazio de alguns de seus métodos, não é o ideal e deve ser evitado ao máximo.

Para garantir que este erro não ocorra, é necessário que o desenvolvedor implemente interfaces mais específicas segmentando melhor cada comportamento para cada caso de uso e regra de negócio.

Dependency Inversion Principle

O princípio da inversão de dependência consiste em passar objetos externos como parâmetros para uma classe a qual dependa deles, através de uma abstração, evitando que a classe dependente mantenha alto acoplamento com relação à este objeto.

Suponha que eu tenha a classe Pedido e essa classe instancia a classe CartaoDeCredito no interior de um dos seus métodos, o ideal seria que a classe Pedido recebesse uma instância de uma abstração MeioDePagamento permitindo que Pedido não tenha uma dependência restrita a CartaoDeCredito.


// Errado, não está seguindo o princípio de inversão de dependência

class CartaoDeCredito{

    public function pagar()
    {
        return pagar('endpoint_do_gateway_de_pagamento');
    }
}


class Pedido {

    public function fecharPedido()
    {
        $cartaoDeCredito = new CartaoDeCredito();
        $cartaoDeCredito->pagar();
    }
}


// Correto, agora está em conformidade com o princípio

abstract class MeioDePagamento{

    abstract function pagar();
}


class CartaoDeCredito extends MeioDePagamento
{
    public function pagar()
    {
        return pagar('endpoint_do_gateway_de_pagamento');
    }
}


class Pedido {

    private $meioDePagamento;

    public function __construct(MeioDePagamento $meioDePagamento)
    {
        $this->meioDePagamento = $meioDePagamento;
    }

    public function fecharPedido()
    {
        $this->meioDePagamento->pagar();
    }

Isso promove a independência da classe Pedido, uma vez que é possível utilizar qualquer instância da abstração MeioDePagamento, também facilitando o desenvolvimento de novas funcionalidades. A classe Pedido mantem contato apenas com uma abstração, e não possui responsabilidades ou mesmo conhecimento sobre detalhes de implementação.

Boas Práticas Para Uma Arquitetura Eficiente

Arthur Barboza — Mon, 16 Jun 2025 15:34:02 +0000

Ao lidarmos com o desenvolvimento de softwares de grande porte e inúmeras regras de negócio, muito provavelmente estaremos lidando com camadas complexas e muitos fluxos de execução, este que deve ser bem arquitetado e planejado pelo desenvolvedor.

Para que o mesmo possa desenvolver uma arquitetura eficiente e com um código sólido, o desenvolver pode fazer uso de boas práticas para obter um código mais legível e bem manutenível.

Fail Fast

O conceito de Fail Fast (podemos traduzir como "falhar rápido") pode ser descrito como a prática de identificar e lidar imediatamente com problemas e erros em sua aplicação. Isso promove a estabilidade do software, uma vez que o mesmo não continuará sua execução com trechos e componentes instáveis.

O Fail Fast está em concordância com os princípios de Engenharia de Software pois o mesmo estimula a identificação e correção de bugs o mais cedo possível (tendo em vista que com o decorrer do crescimento do software, suas alterações e correções de bugs passam a ser mais caras) e promove um software mais legível e fácil de dar manutenção.

Importante destacar que o Fail Fast não se trata exatamente de uma prática sólida, mas sim de um conceito o qual buscamos através de atividades as quais descreveremos algumas a seguir.

Early Return

O Early Return se trata de uma técnica de programação o qual o resultado esperado de uma função se encontra no final do seu corpo. Durante a execução da mesma é realizada várias validações para garantir que no caso de um fluxo falho (não desejado ou inesperado) a execução seja cancelada.

Essa técnica promove maior legibilidade do código, além de diminuir a possibilidade de bugs e permite uma manutenção mais fácil.

Veja o exemplo abaixo :

public function fazerAlgo(AlgumaInformacao $informacao, OutraInformacao $outra)
{
    if ($informacao->temAlgumaCoisa()) {

        if ($informacao->temOutraCoisa()) {

            if ($outra->temSuaCoisa()){

                if (pode_fazer_uma_terceira_coisa($informacao, $outra)){
                    return true;
                } else {
                    echo 'não pode fazer terceira coisa';
                }
            } else {
                echo 'não tem sua coisa';
            } 
        } else {
            throw new NaoTemOutraCoisa('talvez em outro momento...');
        }
    } else {
        echo 'não tem alguma coisa';
    }
}

O código acima apresenta inúmeras condicionais e fluxos de execução, as quais dificultam a leitura do desenvolvedor e resulta em uma manutenção difícil.

Interessante notarmos a existência de alguns "anti-padrões":

Else:
- Dificulta a manutenção pois o mesmo apresenta um fluxo de execução alternativo para quando a condição apresentar valor oposto ao fluxo normal.
Anti-padrão "Flecha" (ou "Arrow"):
- Consiste na presença de inúmeras estruturas condicionais e/ou de repetição encadeadas, resultado no formato de flecha.

Estes problemas apresentados podem ser facilmente evitados caso o desenvolvedor aplicasse a técnica de "Early Return", a qual apenas invertendo os sinais de cada estrutura condicional, seria possível obter um resultado mais limpo e com um fluxo de execução mais claro:

public function fazerAlgo(AlgumaInformacao $informacao, OutraInformacao $outra)
{
    if (!$informacao->temAlgumaCoisa()) {
        echo 'não tem alguma coisa';
        return;
    }

    if (!$informacao->temOutraCoisa()) {
        throw new NaoTemOutraCoisa('talvez em outro momento...');
    }

    if (!$outra->temSuaCoisa()) {
        echo 'não tem sua coisa';
        return;
    }

    if (!pode_fazer_uma_terceira_coisa($informacao, $outra)) {
        echo 'não pode fazer terceira coisa';
        return;
    }

    return true;
}

O "early return" nos proporciona as seguintes melhorias de código :

Código linear com apenas um nível de indentação, possibilitando uma leitura mais fácil
O resultado esperado da função é fácil de encontrar.
Promove um código mais fácil de testar.

KISS (Keep It Simple, Stupid)

O acrônimo significa "Mantenha Isso Simples, Estúpido" e seu conceito reforça a necessidade de mantermos as coisas simples, devido ao hábito de aumentar a complexidade buscando implementar algum design pattern ou conceito que por vezes é muito mais complexo do que de fato necessário.

Este conceito nos lembra de atingir o mesmo objetivo mas por caminhos mais simples, reduzindo complexidades desnecessárias e esforços redundantes.

Um bom exemplo seria um cenário em que um desenvolvedor pretende implementar um modelo de machine learning para resolver determinado problema, quando na realidade este problema poderia ser resolvido verificando algumas breves condições sem grande variabilidade de dados.

Alguns pontos que o desenvolvedor pode se atentar para reduzir a complexidade seria :

Garantir que o nome de variáveis e de métodos transmitam corretamente seu propósito de acordo com o contexto inserido.
Escrever comentários dentro de métodos APENAS quando for necessário.
Garantir que suas classes tenham apenas uma responsabilidade.
Deletar classes, variáveis, métodos e quaisquer trechos de código que não esteja sendo utilizado.

A maior importância de aplicar o princípio KISS, é garantir que quando trabalhando em uma base de código já existente e compartilhada entre vários desenvolvedor, qualquer modificação seja fácil de ser compreendida e até mesmo alterada se necessário.

YAGNI (You Ain't Gonna Need It)

O conceito traduzido "Você Não Vai Precisar Disso" segue o princípio KISS, reforçando a importância de manter simples tudo que for possível de manter simples.

Este princípio consiste na prática de desenvolver apenas aquilo que for realmente necessário, desencorajando o hábito que muitos desenvolvedores praticam de desenvolver algo que acredita que será necessário no futuro.

Isso porque alguns profissionais dedicam demasiado esforço em aplicar otimizações em cenários prematuros e desnecessários, ou mesmo alguma feature ou abstração a qual não se faz necessário atualmente, sendo que sua implementação no futuro pode também se tratar de uma incerteza.

Além disso, essa implementação muito provavelmente acrescentaria maior complexidade no sistema, o que seria prejudicial para o cenário da aplicação.

DRY (Don't Repeat Yourself)

Com o paradigma funcional, o mercado se encontrou com uma das maiores revoluções e progressos na área de desenvolvimento de software : as funções e procedimentos. Ambos representavam um ganho de velocidade muito grande no desenvolvimento do software, pois fornecia ao desenvolvedor recursos suficientes para que o mesmo replicasse trechos de código conforme sua necessidade, aumentando a eficiência do desenvolvimento e também facilitando a manutenção do mesmo.
A Orientação à Objetos foi outro grande passo dado nessa direção, através de classes, métodos e atributos, era possível que os desenvolvedores reutilizassem e encapsulassem funções de acordo com seu contexto.

No entanto, mesmo que os desenvolvedores tenham em mãos tais recursos, é comum que ocorra a implementação de códigos e linhas repetidas em um sistema, aumentando a complexidade do mesmo e dificultando em sua manutenção.

O princípio DRY afirma que uma lógica particular do sistema deve aparecer apenas uma única vez ao longo do código fonte, sendo reutilizado através dos recursos descritos anteriormente.

Exemplo :

class PHPDeveloper 
{
    public function saudacoes()
    {
        echo 'Olá ! Sou um desenvolvedor!';
        echo 'Eu programo em PHP!';
    }
}


class JavaDeveloper 
{
    public function saudacoes()
    {
        echo 'Olá ! Sou um desenvolvedor!';
        echo 'Eu programo em Java!';
    }
}

Neste caso, podemos fazer uso da Herança de Orientação a Objetos, e remover o trecho echo 'Olá ! Sou um desenvolvedor!' de ambas as classes e abstrair para uma classe pai, removendo código duplicado e promovendo a manutenção e legibilidade do sistema.


abstract class Developer {

    public function saudacoes()
    {
        echo 'Olá ! Sou um desenvolvedor!';
    }
}

class JavaDeveloper extends Developer
{
    public function saudacoes()
    {
        parent::saudacoes();
        echo 'Eu programo em Java!';
    }
}


class PHPDeveloper extends Developer 
{
    public function saudacoes()
    {
        parent::saudacoes();
        echo 'Eu programo em PHP!';
    }
}

Porém, é extremamente importante que o desenvolvedor se atente em não aplicar o princípio DRY enquanto não houver código duplicado no sistema, pois o mesmo pode buscar realizar uma abstração mesmo não havendo necessidade (vide princípio KISS e YAGNI).

Conclusão

Os princípios citados acima, descrevem boas práticas as quais foram estudadas e desenvolvidas por profissionais e pesquisadores ao longo dos anos.

Tais práticas promovem uma arquitetura eficiente e um código fácil de trabalhar.

No entanto, os profissionais que forem aplicas estes princípios, devem aplicar com sabedoria e cuidado, pois a má interpretação de um princípio pode resultar em conflito com outros, como consequência o código é prejudicado e afetado, dificultando sua manutenção.

PHP PSR-12 - Resumo

Arthur Barboza — Thu, 05 Jun 2025 15:38:01 +0000

O PSR-12 faz parte do PHP Starndard Recommendations e tem o intuito de reduzir fricções no desenvolvimento de software quando um sistema envolve vários desenvolvedores. Isso é feito a partir da apresentação de várias regras e expectativas sobre como um código PHP deve ser formatado, além de proporcionar o desenvolvimento de ferramentas as quais podem revisar e validar se o código se encontra conforme esperado.

Essa PSR substitui o PSR-2, apresentando recomendações sobre contextos e funcionalidades mais modernas (tendo em vista que o PSR-2 foi apresentado em 2012, um contexto mais antigo).

Geral

Padronização de Código Básico

Código deve se encontrar conforme especificidades da PSR-1
Termo 'StudlyCaps' deve ser interpretado como 'PascalCase'

Arquivos

Todos os arquivos PHP devem terminar com exatamente uma linha vazia (caractere \n, padrão Unix LF), precedida por uma linha não vazia com código ou comentário.
A tag PHP de fechamento "?>" deve ser omitida em arquivos que contenham apenas código PHP

Linhas

Não deve existir um limite rigoso (ou obrigatório) para o comprimento de uma linha.
Um limite tolerável (mas que em situações adequadas pode ser desconsiderado) deve ser de 120 caracteres.
As linhas não deveriam ser maiores que 80 caracteres, linhas maiores deveriam ser separadas em múltiplas linhas subsequentes de não mais do que 80 linhas.
Não deve existir um espaço vazio no final de uma linha.
Linhas vazias podem ser adicionadas para para melhorar a legibilidade e indicar blocos relacionados de código
Não devem existir mais do que um "statement" por linha.

Indentação

Código deve seguir indentação de 4 espaços para cada nível, não deve utilizar "tabs"

Palavras Reservadas e Tipagem

Todas as palavras reservadas e tipagem devem estar em lowercase (quaisquer novas palavras reservadas adicionadas no futuro, devem seguir essa convenção)
Abreviações devem ser utilizadas ("bool" ao invés de "boolean" e etc)

Declaração, Namespace, Import e outros

Um cabeçalho de uma classe PHP pode conter inúmeros statements relacionados à importação de outros componentes (classes, funções, constantes), declaração do atual namespace, comentários e documentações, e outras informações. É necessário que essas informações estejam presentes conforme ordem a seguir :

Abertura de tag PHP (<?php)
Docblock do arquivo
Um ou mais statments de declaração
O namespace do arquivo
Um ou mais import de classes (reconhecimento pelo statement "use")
Um ou mais import de funções
Um ou mais import de constantes
O resto do arquivo

Cada statement deve ser separado em seu respectivo bloco, de forma que cada bloco seja separado por uma linha em branco, mas os mesmos não possuam uma linha em branco em seu conteúdo.

Essa convenção deve ser aplicada mesmo em arquivos que apresentem uma mistura de PHP e HTML em seu conteúdo.

A tag de abertura de PHP deve estar em linha única caso se encontre na primeira linha do arquivo.
Statments de importação não devem começar com a barra invertida
Namespaces compostos não devem ter uma profundidade maior do que 2
Ao declarar tipos estritos (declare(strict_types=1)) em um arquivo que misture PHP e HTML, é necessário que a declaração seja feita na primeira linha com abertura e fechamento PHP
Blocos de statements com a palavra chave "declare" são permitidos e devem se encontrar entre abertura e fechamento de chaves (abertura na mesma linha de palavra chave "declare" e o fechamento em uma nova linha)

Classes, Propriedades e Métodos

Qualquer fechamento de classe não deve ser seguido por um comentário ou statment na mesma linha
Os parênteses devem sempre estar presentes ao instanciar uma nova classe, mesmo que não haja argumentos a serem passados ao construtor

Extends e Implements

As palavra-chaves "extends" e "implements" devem ser declaradas na mesma linha em que o nome de classe
A abertura de chaves da classe deve se encontrar em sua própria linha, o fechamento deve estar na linha seguinte após o fim do corpo da classe
A abertura e o fechamento não deve suceder uma linha vazia
Lista de interfaces a serem implementadas ou estendidas, deve apresentar cada uma em uma nova linha com sua indentação de acordo.

Traits

A palavra chave "use" utilizada para implementar traits, deve ser declarada na linha seguinte à abertura de chaves da classe
Cada inclusão de trait deve estar em uma linha individual e deve utilizar seu próprio "use"
Quando a classe não tiver mais nada além do use statement da trait, o fechamento deve estar presente logo na linha seguinte do mesmo.
- Do contrário, deve haver uma linha em branco após o "use" statement

Propriedades e Constantes

Visibilidade deve ser declarada em todas as propriedades e constantes (caso a versão do PHP seja maior que 7.1)
A palavra chave "var" não deve ser usada para declarar uma propriedade
Não deve haver mais do que uma palavra chave por statement
Propriedades privadas não devem ter seu nome prefixado com um underline para indicar sua visibilidade
Deve haver um espaço na declaração do tipo de variável e o nome

Métodos e Funções

Visibilidade deve ser declarada para todos os métodos
Métodos privados não devem ter seu nome prefixado com um underline para indicar sua visibilidade
Método e nome de função não deve ser declarado com espaço após o nome

Argumentos de Métodos e Funções

Na lista de argumentos, não deve existir um espaço antes de cada linha, e deve existir um espaço após cada linha.
Argumentos com valores definidos por padrão, devem ir no final da lista
Lista de argumentos podem ser divididas entre várias linhas, no qual cada linha é indentada e cada item se encontra em uma linha. Quando assim ocorrer, o primeiro item deve estar na próxima linha da abertura de parênteses.
- Quando assim ocorrer, o fechamento de parênteses e a abertura de chaves devem estar na mesma linha com um espaço entre eles
Quando houver uma declaração do tipo de retorno, o mesmo deve ter um espaço antes dos dois pontos. Ambos devem estar na mesma linha do fechamento de parênteses, sem espaço entre esses.
Declarações de tipo nulas não devem apresentar espaço entre o sinal de interrogação e o tipo de variável.
Quando utilizar o operador de referência ("&"), não deve apresentar espaço entre ele e o nome da variável.
Não deve apresentar espaço entre o operador de argumento "variadic" ("...") e o nome do argumento
Ao combinar os últimos dois operadores citados, não deve haver espaço entre eles.

Abstract, final e static

Abstract e final devem preceder a declaração de visibilidade
Static deve suceder a declaração de visibilidade

Chamadas de Métodos e de Funções

Ao realizar a chamada de um método ou função, não deve existir a presença de nenhum espaço com exceção de um espaço em branco após as linhas que separam os argumentos
Listas de argumentos podem ser divididas entre várias linhas no qual cada linha deve ser um argumento indentado, o primeiro argumento deve se encontrar na linha que sucede a abertura de parênteses.

Estrutura de Controle

Deve haver um espaço após a palavra reservada da estrutura de controle
Não deve haver espaço após a abertura de parênteses
Não deve haver espaço anterior ao fechamento de parênteses
Deve haver um espaço entre a abertura e o fechamento de parênteses
O corpo da estrutura deve estar indentado
O corpo da estrutura deve estar na próxima linha após a abertura de chaves
O fechamento de chaves deve estar na próxima linha após o corpo

If, Elseif, Else

A palavra chave elseif deveria ser utilizada ao invés de else if
Expressões em parênteses podem ser divididas entre várias linhas no qual cada linha deve ser uma expressão indentada, a primeira expressão deve se encontrar na linha que sucede a abertura de parênteses, e operadores booleanos devem se encontrar no começo ou no fim da linha, de forma igual para todas as linhas e não uma mistura entre elas.

Switch, Case

"Case" statement deve estar indentado uma vez a partir do "switch", e a palavra-chave "break" deve estar indentada no mesmo nível em que o corpo do "case"
Deve haver um comentário como "// no break" quando existir uma sequência intencional de um case não vazio para outro

While, Do While, For

Expressões em parênteses podem ser divididas entre várias linhas no qual cada linha deve ser uma expressão indentada, a primeira expressão deve se encontrar na linha que sucede a abertura de parênteses, e operadores booleanos devem se encontrar no começo ou no fim da linha, de forma igual para todas as linhas e não uma mistura entre elas.

Foreach

Um foreach statement deve se parecer conforme o exemplo abaixo

<?php

foreach ($iterable as $key => $value) {
    // foreach body
}

Try, catch, finally

Um bloco try-catch-finally deve se parecer conforme o exemplo abaixo

<?php

try {
    // try body
} catch (FirstThrowableType $e) {
    // catch body
} catch (OtherThrowableType | AnotherThrowableType $e) {
    // catch body
} finally {
    // finally body
}

Operadores

Incremento / Decremento

Operadores de incremento e decremento não devem apresentar espaços entre estes e o operando
Operadores de casting (conversão de tipo) não devem apresentar espaços entre parênteses

Binários

Todos os operadores binários de comparação, aritmética, atribuição e lógicos devem se encontrar entre um espaço em branco e outro

Ternário

Deve apresentar um espaço entre os caracteres ? e :
$variable = $foo ? 'foo' : 'bar';
Quando o operador utilizar sua forma abreviada (sem o operando do meio), o espaço entre os caracteres operadores deve ser omitido
$variable = $foo ?: 'bar';

Closures

Devem ser declaradas com um espaço após a palavra chave 'function' e um espaço antes da palavra chave 'use'.
A abertura de chaves deve estar na mesma linha, e o fechamento na linha seguinte do corpo.
Não deve haver um espaço após a abertura e antes do fechamento de parênteses da lista de argumentos.
Na lista de argumentos, não deve haver um espaço antes de cada vírgula, mas sim um espaço após cada vírgula.
Argumentos com valores 'padrão' devem se encontrar no final da lista de argumentos
Se um tipo de retorno estiver presente, ele deve seguir as regras de retorno das funções e métodos.
- Caso a palavra chave 'use' esteja presente, deve haver dois pontos logo após o fechamento dos parênteses.
Argumentos podem ser separados em múltiplas linhas com cada linha indentada uma vez, deve haver apenas um argumento por linha e o primeiro argumento deve estar na linha seguinte à abertura de parênteses

Classes Anônimas

Devem seguir os mesmos princípios e recomendações das closures
A chave de abertura deve se encontrar na minha lista que a palavra chave "class", a menos que a lista de interfaces implementadas não resultem em quebra de linha
- Caso ocorra uma quebra de linha, a chaves de abertura deve se encontrar na linha seguinte à última interface.

PHP PSR 1 - Resumo

Arthur Barboza — Thu, 29 May 2025 16:23:59 +0000

As PSRs (PHP Standards Recomendations) se tratam de padronizações e boas práticas para o desenvolvimento de software com a linguagem PHP.

A aplicação das PSRs no desenvolvimento de sistemas, tem o intuito de reforçar a qualidade interna do código, resultando em uma boa manutenibilidade e clareza para os desenvolvedores.

Em alguns casos, a não procedência de uma recomendação pode até mesmo resultar problemas como a falta de coesão e clareza do código, ou até mesmo erros de runtime do software.

As PSRs apresentam diretivas tais como nomenclatura de variáveis, abertura de tags PHP, declaração de classes, protocolo HTTP, padrão de carregamento de classes, interface de cacheamento, interface de container e outros.

Segue abaixo resumo da PSR1 - Padrões de Codificação Básica

PSR 1 - Review

Files

Arquivos podem usar as aberturas e fechamentos "<?php ?>" e "<?= ?>" mas não devem utilizar outras variações
O código PHP deve estar em UTF-8
O código PHP não deve declarar símbolos (classes, constantes, funções) e gerar "efeitos colateráis" (configurar variáveis .ini, carregar arquivos manualmente, gerar output, entre outros) no mesmo arquivo

Namespaces e Nomes de Classes

Cada classe deve estar em um arquivo e um namespace de ao menos um nível (conforme padronizado pela PSR-4)
Nome de classes devem ser declarados seguindo formato "StudlyCaps"
Código a partir do PHP 5.3 deve usar namespaces
3.1. Códigos de versões anteriores deve utilizar o pseudonamespace, muito comum no Magento 1 e outros sistemas legados

Métodos, Constantes e Propriedade de Classes

O termo "classe" se refere as classes, interfaces e traits

Constantes de classes devem ser declaradas totalmente em upper case com underline como separador ("UPPER_CASE")
Não há uma convenção de nomenclatura pré-definida da PSR-1 para nomes de propriedades, apenas recomenda o uso consistente para escopos razoáveis (vendor, pacote, classe, método)
Métodos devem ser declarados em "camelCase"