Padrão de código do WordPress, linters e dinheiro

Já falei sobre linters aqui no blog antes, mas isso já tem dois anos. Naquele post falei apenas do linter para código PHP, mas ainda vale a pena ler. Neste texto vamos ver um linter para JavaScript e outro pra códigos CSS (e SASS também).

Por que padrões de código são importantes?

Como eu falei no outro texto, seguir algum padrão de código é fundamental. Um dos aspectos importantes no desenvolvimento de softwares é a sua facilidade de manutenção. Seguir um padrão aumenta muito a legibilidade do seu código e, portanto, facilita seu entendimento e reduz o tempo gasto em manutenção.

Outra coisa importante, e que pouca gente comenta, é que seguir o padrão de código do WordPress pode ser o diferencial para conseguir aquela vaga ou aquele projeto. Espera-se que um desenvolvedor com foco em WordPress siga o padrão de código da ferramenta e, com certeza, isso é levado em conta na hora de decidir qual currículo selecionar.

Work smarter, not harder. Para ganhar mais, você não precisa trabalhar mais, precisa trabalhar melhor. Seguir um padrão de código é entregar um código com mais qualidade.

Você pode até não gostar de algumas coisas do padrão de código do WordPress. Você tem esse direito. Eu também não gosto de crase, regras de acentuação, concordância, hifens e mais um monte de coisa, mas infelizmente sou obrigado a (tentar) fazer tudo isso do jeito certo quando estou escrevendo um texto. A lógica é a mesma.

Sua empresa pode não ter foco só em WordPress, acontece. Se for o caso, esse texto também pode ajudar na aplicação de outros padrões, como os padrões sugeridos pelo próprio PHP.

Seguir o padrão de código do WordPress pode significar ganhar mais dinheiro SIM.

O que é um linter?

Um linter é um analisador estático de código. Estático porque ele não executa o seu código, ele simplesmente analisa e verifica se a sintaxe está correta. Os linters funcionam da mesma que os corretores ortográficos: eles não interpretam o texto, não fazem ideia se o que está escrito faz sentido, mas verificam se tudo está escrito da forma certa.

Formas de usar

Você pode usar os linters de muitas formas. Vou listar algumas aqui e é bem provável que você queria usar todas elas.

No seu editor de código

No outro texto, eu expliquei como usar o PHPCS no Atom. De forma geral, em todos os editores isso funciona da mesma forma:

Faça o linter funcionar fora do seu editor;
Configure o linter para usar o padrão de código correto;
Instale o add-on correspondente ao linter no editor e
Configure o add-on para apontar para a instalação correta do linter.

No hook pre-commit do Git

Você com certeza está versionando seu código, certo? (Essa pergunta só tem uma resposta certa). Mesmo que você seja um freelancer que sempre trabalha sozinho, versione o seu código. Serve tanto como backup quanto como uma forma de recuperar modificações de código. Crie repositórios privados no GitHub ou no Bitbucket e torne isso parte da sua rotina. Vai por mim.

Usando os pacotes Husky e lint-staged do npm, é bem fácil fazer com que os linters analisem seu código antes de enviar um commit no git e impedirem caso o código esteja fora do padrão. Isso daria um outro post, mas basicamente esse é o código que você precisa criar no seu package.json (copiado do pessoal do WooCommerce):

{
	...
	"devDependencies": {
		...
		"husky": "x.x.x",
		"lint-staged": "x.x.x",
	},
	"husky": {
		"hooks": {
			"pre-commit": "lint-staged"
		}
	},
	"lint-staged": {
		"*.php": [
			"php -d display_errors=1 -l",
			"phpcs -s -p -n"
		],
		"*.scss": [
			"stylelint --syntax=scss --fix",
			"git add"
		],
		"*.js": [
			"eslint --fix",
			"git add"
		]
	},
}

Como parte do processo de CI

Essa não é muito a minha área, mas você também pode incluir o lint do seu código como uma etapa do seu processo de CI. Através de testes automatizados é possível verificar se um código enviado através de um Pull Request é válido e decidir entre fazer o merge ou não baseado no resultado desse teste.

Parece complicado, mas não é. Funciona assim:

Fulano envia um Pull Request com um código qualquer. Não sabemos se ele está com o pre-commit configurado como comentamos no item anterior.
Sua ferramenta de CI (Travis, CircleCI ou outra qualquer) percebe que há um novo Pull Request e analisa o código.
O resultado do teste faz parte da tela do Pull Request. Se o código não passa na verificação, o autor do PR pode corrigir os erros sem que a revisão manual de outra pessoa seja necessária.

Formas de instalar

Existem basicamente duas formas de usar um linter:

Globalmente

Se você pretende usar os linters só com o seu editor de código, instalá-los uma vez só pode fazer mais sentido. Não é tão recomendado porque não será possível configurar nenhuma especificidade por projeto ou compartilhar configurações com a sua equipe, mas eu sei que em alguns cenários isso parece melhor do que criar um projeto para um código onde você só vai mexer em duas linhas e nunca mais olhar para aquilo.

Eu expliquei como fazer com o PHPCS lá no outro texto, com mais informações na próxima seção desse texto aqui. Para pacotes do NPM é só passar o parâmetro -g, mas com o ESLint isso não vai funcionar. Mencionei como resolver na seção dedicada a ele abaixo.

Por projeto (recomendado)

Instalando e configurando os linters por projeto, você consegue aproveitar ao máximo todos os recursos possíveis. Compartilhar com a (e poder cobrar da) equipe, modificar pequenas regras de acordo com o projeto, usar na sua ferramenta de CI e no pre-commit são algumas delas. Normalmente os add-ons dos editores funcionam bem com configurações por projeto logo de cara, então isso não deve ser uma preocupação.

Existe uma possibilidade remota de um determinado add-on não funcionar se, por exemplo, os arquivos de configuração estiverem dentro do tema, mas você abrir o projeto algumas pastas acima (como a instalação inteira do WP). Se for esse o caso, é só configurar o add-on para que ele leia da pasta certa. No VS Code vá até a aba OUTPUT e altere o valor do dropdown para ver o log do linter e corrigir qualquer eventual erro.

Linters para PHP, JS e CSS

Existe mais de um linter para cada uma dessas linguagens. Vou deixar aqui a minha indicação e também alguns passos para fazer a instalação sem (muitos) problemas.

Linter de PHP: PHP_CodeSniffer (PHPCS)

No texto sobre Atom, Linters, PHP Code Sniffer e WP Coding Standards. eu expliquei em detalhes como instalar esse linter. Seja por projeto ou globalmente, é só você instalar os seguintes pacotes com o Composer (o gerenciador de pacotes PHP):

Esse último serve para instalar automaticamente o padrão do WordPress no PHPCS, facilitando o processo.

O PHPCS vem com um irmãozinho, o PHPCBF. No VS Code eu uso essa extensão para que alguns problemas no código sejam resolvidos automaticamente.

Linter de JavaScript: ESLint

O ESLint é um pacote do NPM (se você não sabe o que é isso, tem vídeo lá no canal). Além do ESLint, você vai precisar do pacote com o padrão de código JS do WP para o ESLint, além de configurar o ESLint para aplicar esse padrão. Você pode configurar o ESLint direto no seu arquivo package.json ou criando um arquivo .eslintrc (esse arquivo pode ter várias extensões diferentes). Basicamente é só você executar:

npm install eslint @wordpress/eslint-plugin --save-dev

Isso vai incluir os dois pacotes no seu package.json. Se você ainda não tem um package.json é só criar um executando npm init. Depois, você pode criar um arquivo .eslintrc com o seguinte conteúdo:

{
	"extends": [
		"plugin:@wordpress/eslint-plugin/recommended"
	],
	"env": {
		"jquery": true
	}
}

O "jquery": true ali ajuda o ESLint a entender as funções nativas do jQuery.

Instalar os dois pacotes globalmente não vai funcionar (eu não consegui pelo menos). Se você for usar o ESLint só no seu editor de código, você pode criar uma pasta e fazer dela um projeto. Depois é só apontar o seu add-on para essa pasta. Testei no VS Code e funcionou bem.

A CLI do ESLint aceita o parâmetro --fix para corrigir automaticamente alguns erros. A extensão que eu uso no VS Code adiciona uma entrada na palheta de comandos para isso. É só apertar Ctrl+Shift+P e achar o ESLint: Fix all auto-fixable Problems.

Linter de CSS, SASS e LESS: stylelint

O stylelint também é um pacote do NPM e, assim como o ESLint, também precisa de um outro pacote com o padrão de CSS do WordPress. Seu esquema de configuração também é bem parecido com o do ESLint (todos os linters se parecem, aliás). Tão simples quanto o anterior, só rodar o comando abaixo deve ser o suficiente para incluir os dois pacotes:

npm install stylelint stylelint-config-wordpress --save-dev

Depois é só criar um arquivo chamado .stylelintrc e colocar o padrão que você quer usar. Eu normalmente uso SASS, então fica assim:

{
  "extends": "stylelint-config-wordpress/scss"
}

Instalar o stylelint globalmente funcionou bem aqui na minha máquina. A única configuração que eu precisei fazer no VS Code foi desativar o lint nativo do editor para arquivos .css e .scss, senão ele acaba usando os dois ao mesmo tempo.

A CLI do stylelint também aceita o parâmetro --fix para corrigir automaticamente alguns erros. Infelizmente a extensão que eu uso no VS Code para o stylelint não vem com a formatação automática. É preciso executar o código abaixo:

npx stylelint **/*.scss --fix

Espero que esse texto mude a forma como você cria seus códigos e ajude a conquistar vagas e projetos melhores e maiores! Se gostou não se esqueça de comentar aqui embaixo e compartilhar com seus amigos 🙂