Eu tenho uma ferramenta de análise estática no Sublime Text há muito tempo, mas, na maior parte desse tempo, tenho tido o CodeSniffer e seu PSR-2 desativados. Não consigo lembrar por que tenho feito isso, até que o ativei novamente. De repente, ele começou reclamar de código que eu considerava perfeitamente compatível.

Isso me lembrou de múltiplas conversas que tive com outras pessoas no FIG e na comunidade em geral, sobre como o CodeSniffer frequentemente força regras da especificação PSR-2 que não existem ou que não significavam exatamente aquilo que estava escrito.

Alguns meses atrás, eu defini a missão de colocar o CodeSniffer alinhado com o que o PSR-2 realmente é.

A história

Isso teve início baseado nesses problemas que eu chamo de “argumentos multilinha”. Em outras palavras, isto deve ser válido:

somefunction($foo, $bar, [
  // ...
]);

Depois de falar com Greg Sherwood, ficou claro que ele não efetuaria mudanças nas regras do PHP CodeSniffer sem que o próprio PSR-2 fosse modificado para esclarecer as intenções, e o FIG tem sido muito claro sobre o fato de que ninguém querer mudar os PSRs uma vez que eles tenham sido aprovados.

Então, em vez de reclamar, decidi definir os passos necessários para resolver isso.

1. Fazer uma enquete com o grupo e perguntar se uma Errata pode ser uma boa ideia (conforme sugerido inicialmente por Larry Garfield).
2. Criar uma lista de potenciais Erratas para o PSR-2.
3. Fazer um pull request da primeira parte da Errata para o PSR-2.
4. Fazer o Greg implementar a mudança.
5. Repetir até que não houvesse mais problemas.

O problema é que metade dessas coisas necessitava de duas semanas de votos, portanto seria um longo processo.

Criei uma enquete na lista de e-mails do FIG para ver se as pessoas concordariam com a ideia de permitir uma Errata para os meta documentos PSR. Essa é uma boa maneira de conseguir alguns prós e contras e ter uma discussão, o que de fato aconteceu, mas não foi nada grande.

As pessoas pareceram felizes com a ideia, então eu criei uma votação para a Errata. A votação passou com 20 votos a favor e nenhum contra, entre 27 pessoas. Um grande sucesso.

Três semanas se passaram a partir desse ponto, e decidimos apenas que permitiríamos uma Errata para PSRs em geral. O próximo passo seria implementar, de fato, a Errata específica para a discrepância número 1 na minha lista: “argumentos multilinha”.

Criei uma enquete para trabalhar os exemplos que as pessoas sentiam que eram válidos. Todos pareciam acreditar que isto era ou deveria ser válido:

somefunction($foo, $bar, [
  // ...
]);

Alguns discordaram que o código a seguir era válido:

somefunction($foo, $bar, [
  // ...
], $ban);

Mas a maioria se pronunciou, e eu usei a enquete como base para um pull request, que foi então levado para votação. A votação foi aprovada dois meses depois – o PHP CodeSniffer 1.4.7 era algo que continha todas essas mudanças!

Próximos passos

O suporte para PSR-2 do CodeSniffer está longe de ser perfeito. Apesar de reportar algumas discrepâncias, descobri alguns bugs e, geralmente tuitando sobre o assunto, tenho relatos de outros problemas nos quais o CodeSniffer reclamaria sobre coisas das quais ele não deveria ter motivo para reclamar.

Construí um gist do PSR-2 versus CodeSniffer PSR-2 no qual pessoas podem discutir essas questões e reportar novas. Já chegamos a cinco, e vamos tê-las corrigidas na versão 1.4.7, mas ainda temos duas sobrando.

Por exemplo, alinhamento de comentários é uma discussão em aberto, mas algumas pessoas disseram que o CodeSniffer deveriam ignorar comentários e permitir que pessoas os coloquem onde quer que queiram. Se o PSR-2 não diz nada sobre isso, o CodeSniffer não deveria sinalizar sobre isso.

Por que se importar?

Eu me importo com isso porque, apesar das palavras traiçoeiras, o PSR-2 é na verdade um padrão muito bom. Hindsight diz que pedaços do PSR-2 poderiam ser muito melhores, mas eu estava a tempo da votação, e minhas primeiras leituras nunca consideraram isso um problema. É normal que essas coisas surjam apenas durante a fase de implementação. Isso é essencialmente o porquê de eu ter proposto a votação do PSR-4 no último minuto, porque o FIG precisa focar num vocabulário mais preciso o mais rápido possível.

Isso significou um enorme investimento de tempo e esforço, recebendo votos, enquetes, moderando discussões etc. e não está pronto ainda, mas tudo valeu a pena.

Minha namorada já reclamou diversas vezes sobre eu discutindo na Internet, mas eu fico feliz de estas questões terem sido resolvidas:

• Eu posso agora seguir o PSR-2 sem definir um conjunto personalizado de regras.
• Meus funcionários podem agora seguir o PSR-2 sem que eu tenha que mostrar para eles como definir um conjunto personalizado de regras.
• Muitas pessoas que odeiam o PSR-2 talvez percebam agora que ele não é tão ruim assim.
• Se elas pararam de odiar tanto o PSR-2, elas prestarão atenção aos PSRs futuros.
• Temos agora um processo de corrigir confusões futuras de sentenças potencialmente mal escritas (mas devemos obviamente tentar escrever as coisas melhor em primeiro lugar).

Se você encontrar mais discrepâncias, entre em contato comigo via Twitter, mas se você sugerir que criemos um item de errata para permitir tabs em vez de espaços, usarei o meu porrete com força.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://philsturgeon.co.uk/blog/2013/10/psr2-v-codesniffer-psr2