Padrões Básicos de Codificação via PSR-1
Ontem, falei brevemente sobre uma lógica para usar PSRs versus os Padrões de Codificação do WordPress e o quando e o porquê de ambos. Mas isso não significa que não seja sem seus pontos de confusão, especialmente se você está apenas começando com eles, certo?
Com isso, quero dizer: digamos que você trabalha com os Padrões de Codificação do WordPress há anos (porque eu posso me identificar) e agora há todo esse novo conjunto de regras e diretrizes a seguir. Mas não é uma simples questão de alterar alguns espaços em branco e renomear arquivos.
Há outros pontos a seguir, e cada um é descrito em um número, literalmente (PSR-1, PSR-2 e assim por diante), de como algo deve funcionar.
Então, quando se trata apenas dos padrões básicos de codificação descritos no PSR-1, quais são algumas áreas problemáticas que podemos encontrar como desenvolvedores do WordPress?
Padrões básicos de codificação (e efeitos colaterais)
Não tenho planos de revisar cada um dos documentos e refazer o que já podemos aprender simplesmente lendo-os, mas acho que há algo a ser dito sobre pegar algo que muitos de nós fazemos ou experimentamos e ver como isso pode mudar dentro o contexto do WordPress.
Pegue os Efeitos Colaterais do Padrão Básico de Codificação (ou PSR-1 ), por exemplo:
Um arquivo DEVE declarar novos símbolos (classes, funções, constantes, etc.) e não causar outros efeitos colaterais, ou DEVE executar lógica com efeitos colaterais, mas NÃO DEVE fazer as duas coisas.
A frase “efeitos colaterais" significa execução de lógica não diretamente relacionada à declaração de classes, funções, constantes, etc., meramente pela inclusão do arquivo.
Pessoalmente, acho a segunda frase a chave para entender e evitar ao máximo os efeitos colaterais em nosso código. Ou seja, qualquer coisa que nossas classes façam deve ser autocontida ou coesa com algo que possa ter sido injetado de alguma forma.
Independentemente disso, encontrar o código que introduz um efeito colateral e limpá-lo não deve ser muito difícil. Na verdade, vou me usar como exemplo.
Veja este trecho de código específico :
Este código é direto de Toggle Admin Notices. Concedido, é simples, e o repositório mostra uma nota de como alterá-lo. Isso demonstra o ponto, no entanto, certo?
Qual é a solução? Isso vem na forma de Autoloading (que também é abordado no PSR-4 ). E daí se eu o refatorasse, para que ele seguisse o PSR-1 corretamente? Então, uma maneira de refatorar pode ser assim :
Este é um grande exemplo? Provavelmente não. Mas há mais do que apenas incluir arquivos. Incluir esses arquivos é fazer com que esse único arquivo introduza uma variedade de efeitos colaterais.
Isso significa que esse arquivo sozinho é responsável por fazer muito mais do que apenas essas quatro linhas de código. Pense nisso como incorporar tudo o que outros arquivos implementam. Torna-se mais complexo nesse ponto.
Então pegue essa ideia e mova-a para um sistema muito maior e você poderá ver como e por que isso seria problemático.
Claro, também existem formas alternativas. E este é apenas um exemplo. Autodepreciativo também. A questão não é tanto mostrar uma maneira definitiva de fazer isso, mas começar a semear pensamentos sobre como projetamos, planejamos, construímos e incorporamos classes.
E as visualizações?
Quando se trata de escrever plugins, sou parcial em tratar o que os usuários verão como visualizações. Mas parece haver um problema aqui: é considerado uma prática ruim incluir arquivos, pois apresenta efeitos colaterais.
Portanto, não queremos gerar lógica em nossas classes, mas também queremos separar a apresentação da lógica de negócios.
O que devemos fazer?
A diferença… é que vamos usar programação orientada a objetos para fazer isso. Vamos projetar uma classe que gera HTML usando o template PHP.
Isso foi abordado em profundidade por outra pessoa, e eu recomendo a leitura desse post específico para tirar a ideia dos efeitos colaterais, evitá-los e incorporar práticas sólidas o máximo possível.
…E Ativos e Arquivos Relacionados?
Eu sei: a ideia de se afastar dos efeitos colaterais (quanto mais identificá-los) pode ser estranha no começo, especialmente quando você pensa em certas coisas que fizemos por tanto tempo.
E pode levantar questões como: Incluir arquivos JavaScript ou arquivos CSS está errado? Provavelmente é assunto para outro post. Lembre-se, porém, de que existem funções centrais da API diretamente relacionadas a isso, e elas podem ser parte de uma classe estritamente responsável por fazer isso.
Se o objetivo de uma classe é fazer exatamente isso e apenas isso e usa funções de API para fazer isso, eu diria que provavelmente está tudo bem.
Mas estou divagando sobre isso por enquanto (e talvez seja um tópico para os comentários ou, novamente, outro post).
Em vez disso, mantenha suas aulas enxutas e objetivas. Eles devem fazer como o PSR-1 afirma e evitar fazer coisas como “[declarar] novas classes, funções, constantes, etc.” e “[executar] lógica com efeitos colaterais”.