O que é PSR e por que você provavelmente não está pensando no que acha que é
Você digitou algo relacionado a PSR no Google e trouxe a pergunta pra cá. Vou assumir que o contexto é desenvolvimento web ou PHP, já que esse é o uso mais comum do termo. Se for outra coisa, avisa nos comentários que eu ajusto. PSR significa PHP Standard Recommendation. São recomendações de padronização criadas pelo PHP-FIG (Framework Interop Group). O grupo existe desde 2009 e define convenções que frameworks e bibliotecas PHP seguem para interoperarem entre si. Sem o PSR, cada framework faria o seu jeito e tudo dava errado na hora de integrar.
google o que significa psr
Quando alguém pesquisa "google o que significa psr", geralmente é porque viu a sigla em um erro do Composer, num README de biblioteca ou num tutorial. A confusão acontece porque o Google retorna resultados dispersos — tem gente falando de PSR como se fosse uma regra rígida, tem gente tratando como se fosse mera opinião. A realidade é que as PSRs são padrões voluntários, mas a indústria inteira convergiu para segui-las. Não seguir PSR num projeto PHP hoje é como entregar código sem formatação num ambiente corporativo: funciona, mas ninguém vai querer dar manutenção.
As PSRs que realmente importam
Existem dezenas de PSRs. A maioria das pessoas só precisa conhecer quatro ou cinco. As demais são específicas demais para o dia a dia. PSR-1: Basic Coding Standard — define o mínimo obrigatório: arquivos devem usar apenas tags PHP de abertura (sem "
?"), classes e métodos devem seguir camelCase ou PascalCase, e constantes UPPER_SNAKE_CASE. É a base. Se um código não obedece ao PSR-1, você já sabe que precisa revisar a fundamentação antes de avançar.
PSR-2: Coding Style Guide — expande o PSR-1 com regras de formatação: indentação de 4 espaços, chaves no mesmo nível da declaração em algumas estruturas, namespaces no topo do arquivo, e a regra de ouro de que cada arquivo deve ter exatamente uma classe. Muitos desenvolvedores ainda brigam com isso, mas o PHPCodeSniffer exige isso e não há como fugir. PSR-4: Autoloading Standard — talvez a mais importante na prática. Define como nomes de classes se mapeiam para caminhos de arquivos. Se você usa Composer, está usando PSR-4 automaticamente, mesmo que não saiba. O autoload do Composer é inteiramente baseado nesse padrão. A regra central: o namespace corresponde a um diretório, e a classe corresponde a um arquivo. Nada de includes manuais espalhados pelo código.
PSR-12: Extended Coding Style — evolução do PSR-2. Mais flexível em alguns pontos, mais rigoroso em outros. A grande diferença prática é que o PSR-12 permite declarations multi-line e short-open tags são desencorajadas de forma mais explícita. O Laravel, o Symfony e a maioria dos frameworks modernos seguem PSR-12. PSR-16: Simple Cache — interface padronizada para cache. Define métodos como get(), set(), delete(), getMultiple(), setMultiple() e deleteMultiple(). Se você precisa trocar uma implementação de cache (digamos, de file-based para Redis) sem reescrever toda a lógica, usa PSR-16. Na prática, quase todo mundo acabou indo para o PSR-6 (Cache-Interop), que é mais moderno, mas o PSR-16 ainda aparece em código legado.
PSR-3: Logger Interface — define os métodos de logging: debug(), info(), notice(), warning(), error(), critical(), alert(), emergency(). Projetos como Monolog implementam essa interface. A utilidade real aparece quando você troca de library de logging: basta trocar a implementação, não o código que chama os métodos.
Um problema real que eu encontrei e como resolvi
No início de 2023, migrei um sistema antigo que usava autoload manual com spl_autoload_register para Composer com PSR-4. O problema específico foi que o código antigo tinha classes em namespaces que não mapeavam diretamente para a estrutura de diretórios. Exemplo prático: a classe App\Services\User estaba no arquivo app/Service/User.php, violando PSR-4 porque o namespace tinha "Services" no plural mas o diretório era "Service" no singular. O Composer simplesmente não carregava a classe e o autoloader não mostrava erro nenhum — só falhava silenciosamente. A solução foi rodar composer dump-autoload -o após corrigir a estrutura de pastas e renomear a classe para refletir o namespace correto. Antes disso, gastei umas 3 horas rastreando o problema porque o erro era interpretado como problema de permissão ou cache, não como divergência de namespace.
O que ninguém te conta sobre PSR
A primeira coisa que os iniciantes ignoram: PSR não é lei. Nenhuma agência reguladora cobra PSR. O PHP não valida PSR. A única entidade que faz cumprir PSR é o PHPCodeSniffer (via phpcs) e o próprio Composer. Fora isso, é questão de convivência em equipe e de ecossistema. A segunda coisa: seguir PSR não garante código bom. Já vi projetos absurdamente bem-formatados segundo PSR-12 que eram estruturalmente péssimos. PSR resolve problemas de padronização, não de arquitetura. Não confunda as duas coisas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A terceira, e talvez a mais importante: as PSRs evoluem. O PHP-FIG já atualizou várias delas. PSR-12 substituiu e expandiu PSR-2. PSR-6 substituiu parcialmente PSR-16. Quando começar um projeto novo, veja qual versão está vigente, não qual estava vigente quando você aprendeu. A diferença entre usar PSR-4 de 2014 e PSR-4 atualizado pode significar compatibilidade com PHP 8.3 ou não.
Quando PSR não é a resposta certa
Se o seu projeto é um script único, sem dependências externas, sem equipe, rodando em servidor compartilhado com PHP 5.6 — PSR é overkill. Você gasta mais tempo configurando o autoloader do que escrevendo código útil. Nesses casos, um include tradicional resolve e não vale o esforço de padronização. Se você está usando PHP apenas para renderizar templates simples e não tem classes complexas, também não há motivo para PSR. A sobrecarga administrativa não compensa o benefício.
Se o seu time não tem revisão de código e ninguém vai ler o código dos outros, PSR não vai resolver nada. Padrão sem processo de manutenção vira letra morta em dois meses.
Como verificar se seu código segue PSR na prática
O método mais direto é instalar o PHPCodeSniffer e rodar contra seu projeto. Composer é a via mais limpa: composer require --dev squizlabs/php_codesniffer
Depois, execute: vendor/bin/phpcs --standard=PSR12 src/
Isso mostra todos os desvios. O output é detalhado: linha, coluna, tipo de erro e qual regra foi violada. Na maioria dos casos, dá para rodar o phpcbf (o fixador automático) que corrige a maioria dos problemas sozinho: vendor/bin/phpcbf --standard=PSR12 src/
Cuidado com o phpcbf. Ele corrige a formatação, mas não corrige lógica. Uma classe que estava em um namespace errado vai continuar em namespace errado, só que agora com os espaçamentos certinhos.
Links úteis
O repositório oficial das PSRs fica no GitHub do PHP-FIG: github.com/php-fig/fig-standards. Todas as PSRs estão listadas lá com a proposta original, o histórico de votes e o status (accepted, superseded, deferred). A página é seca, mas é a fonte primária — não confie em tutoriais de terceiros quando o documento oficial está disponível. Para validação automática no dia a dia, o PHPCodeSniffer com o padrão PSR12 cobre 95% dos casos que você vai encontrar. Para CI/CD, configure o phpcs como stage no seu pipeline. Se passar, o código entra. Se não passar, o pipeline falha. Isso elimina a necessidade de brigar com formatted por código review.
