Usando os PSRs (versus os padrões de codificação do WordPress)

Neste ponto, não sei quantos artigos escrevi sobre a importância dos Padrões de Codificação do WordPress (o suficiente para linká-los aqui, aqui e aqui, eu acho, o que conta para alguma coisa).

Mas depois de fazer projetos suficientes para clientes e trabalhar com desenvolvedores que são muito mais inteligentes e familiarizados com ferramentas avançadas do que eu, estou em um lugar onde estou optando por começar a usar PSRs no desenvolvimento do WordPress WordPress.

Ah, o drama, certo?

Sério, no entanto. Existem razões para isso, e há momentos em que acho que os Padrões de Codificação do WordPress ainda devem ser usados, mas estou rapidamente me convencendo de que construir qualquer projeto moderno em cima do WordPress deve usar ferramentas PHP mais modernas (que eu mencionarei brevemente mais tarde).

Usando PSRs no desenvolvimento do WordPress

Posts como esse geralmente trazem algum debate ou resposta dramática dentro do WordPress, o que não é minha intenção nem é algo que eu acho necessário. Para ser honesto, conheço um bom número de outros desenvolvedores que fizeram isso há muito tempo, falaram sobre isso, seguiram em frente e continuaram a ter sucesso tanto em seus negócios quanto em seus projetos de hobby.

Mas dado que eu falei tanto sobre um versus o outro, achei que vale a pena compartilhar minha opinião sobre por que estou optando por fazer essa mudança agora e a lógica por trás disso.

1 Paridade com a comunidade PHP

Ao longo do último ano, e realmente nos últimos meses deste ano, fiquei mais acostumado a:

• amigos desenvolvedores mais experientes em PHP endossando ferramentas que esperam que os PSRs sejam adotados,
• o uso de //@codingStandardsIgnoreStart e //@codingStandardsIgnoreEnd no meu código,
• conjuntos de regras personalizados para meus projetos com base nos ambientes nos quais eles estão implantados,
• e mais.

Em última análise, trata-se de querer manter a paridade (ou um pouco dela) com a maior comunidade PHP em geral enquanto também escreve código legível e baseado em padrões em cima do WordPress. E também gostaria de usar algumas outras ferramentas e versões mais recentes de ferramentas existentes (que discutirei mais adiante neste post).

2 Problemas com ambientes modernos

No momento em que escrevo este post, o PHP CodeSniffer (que é necessário para executar os Padrões de Codificação do WordPress) está na versão 3.0.2. No entanto, existem problemas de compatibilidade com PHPCS e com os Padrões de Codificação do WordPress. Especificamente :

A nova versão do PHP CodeSniffer tem alguns recursos interessantes, mas apresenta mudanças importantes, o que significa que os padrões de codificação do WordPress não são compatíveis.

Para ser claro (e devido à natureza do software), é uma questão de tempo até que seja corrigido. Mas se você estiver trabalhando em uma base de código e estiver usando o Composer e os Padrões de Codificação do WordPress, você precisará definir explicitamente a versão do PHP CodeSniffer em vez da versão mais recente atualmente.

Além disso, tive problemas com clientes em que a não adoção dos PSRs no desenvolvimento do WordPress resultou em um comportamento estranho ao implantar o código. Talvez se possa argumentar que eles deveriam ajustar o ambiente, mas se eles estão trabalhando para ter as ferramentas mais modernas disponíveis para as pessoas que as utilizam, por que regredir?

3 Compatibilidade com ferramentas modernas

Finalmente, há uma série de ferramentas modernas que não consegui usar, muito menos aprender, por causa do que é e do que não é suportado pela natureza do controle de versão.

Por exemplo, estávamos usando o GrumPHP em um projeto recente que tem suporte para uma variedade de ferramentas, mas não pudemos usar, digamos, o PHPMD devido à falta de adoção dos PSRs. No que me diz respeito:

• Quero melhorar continuamente minhas habilidades como desenvolvedor (e, neste contexto, desenvolvedor PHP),
• a falta de suporte para ferramentas mais modernas me coloca em um padrão de espera que de outra forma eu não experimentaria,
• Quero continuar trabalhando com o WordPress, mas com um fluxo de trabalho mais moderno

E agora, não usar os PSRs está criando uma lacuna entre o que o resto da comunidade PHP está fazendo e o que o WordPress está fazendo. Então, eu gostaria de seguir em frente enquanto mantenho o trabalho em projetos em cima do software que ainda gosto de usar.

E quanto aos padrões de codificação do WordPress

Então, o que isso significa sobre os Padrões de Codificação do WordPress e posts anteriores? Nada realmente. Do jeito que eu vejo: Os Padrões de Codificação do WordPress devem ser usados ​​sempre que você estiver trabalhando no WordPress Core ou algo que será integrado a ele.

Mas se você está trabalhando em algo que fica em cima do WordPress ou algo que usa o WordPress como base e você pode usar os PSRs no desenvolvimento do WordPress junto com ferramentas que podem ajudar a aumentar a qualidade da base de código que você está construindo.

Então, pelo menos por enquanto, essa é a perspectiva que vou adotar. Estou ansioso para ver como isso vai se desenrolar nos próximos meses. E, como para qualquer outra coisa que compartilhei, compartilharei os aspectos de fazer essa mudança.