Como Padronizar Códigos com Style Guides e ESlint, EditorConfig e Prettier
Como Padronizar Códigos com Style Guides e ESlint, EditorConfig e Prettier
Afinal, você já parou para pensar se o seu código é bem organizado, de maneira que qualquer programador consiga compreendê-lo facilmente?
Nada é mais inconveniente do que desenvolver em um projeto com o código mal organizado e não padronizado. Isso gera grandes dificuldades para que outros programadores consigam compreender ou manter o código.
Nós programadores não devemos desenvolver sistemas pensando apenas em si. Mas também precisamos levar em consideração as pessoas que podem ter acesso ao nosso código.
E, para solucionar esse problema, surgiram as Styles Guides (ou guias de estilos), que definem regras que serão aplicadas em nossos códigos com auxílio de algumas ferramentas. Isso para manter os códigos padronizados e organizados, aumentando a produtividade entre todos os desenvolvedores.
O que são Style Guides?
Style Guides são guias que definem um conjunto de padrões que nos orientam a manter um código bem organizado e estruturado. Eles abordam questões como nomeação de arquivos e variáveis, sintaxe, comentários, importação de módulos, entre vários outros temas.
Veja um exemplo de uma das regras para formatação de estruturas em blocos:
Atualmente, existem alguns guias que são muito utilizados em diversos projetos como:
- Google Style Guides que abrange diversas linguagens de programação;
- Airbnb React/JSX Style Guide para a biblioteca React.
Cada guia define suas próprias convenções. Então, antes de escolher qualquer guia, é importante analisar qual melhor se adequa ao projeto e ao time de desenvolvimento.
Como aplicar um Style Guide em projetos?
Além de aplicar as convenções de um Style Guide durante a escrita do código, algumas dessas convenções são tarefas repetitivas. Dessa forma, podem ser automatizadas com o uso de algumas ferramentas como ESLint, EditorConfig e Prettier.
Neste artigo, vamos conhecer um pouco sobre cada uma delas.
ESLint
O ESLint é uma das ferramentas mais utilizadas para identificar e corrigir código JavaScript/Typescript que não segue os padrões estabelecidos. Essa ferramenta permite ser configurada com um Style Guide já consolidado ou de forma personalizada, de acordo com as regras disponíveis.
Assim, pode ser utilizado para identificar possíveis erros na lógica, na formatação ou sugestões de melhorias no código.
Para utilizar o ESLint, precisamos instalar a dependência no projeto com yarn add -D eslint
, iniciar a configuração com yarn run eslint –init
e definir as regras customizadas ou utilizar template já consolidado.
No arquivo criado na raiz do projeto com o nome .eslintrc.json
, na propriedade “rules”
, podemos adicionar, editar ou sobrescrever alguma regra. Como no exemplo a seguir, que define os nomes de funções e variável no estilo camelcase (não permite comentários na mesma linha do código, o ponto e vírgula deve ser inserido no final da linha e deve ser utilizado aspas duplas, consecutivamente):
Para quem utiliza o VS Code, poderá instalar o plugin ESLint, e quando um trecho de código não seguir essas regras, será apresentado um erro na linha como no exemplo abaixo, solicitando a correção:
O ESLint possui diversas outras regras e possibilidades de integração com outras ferramentas para tornar automática a aplicação dessas regras, como veremos em um tópico posterior.
Mais regras do SLint: https://eslint.org/docs/latest/rules/
EditorConfig
O EditorConfig é uma ferramenta utilizada para padronizar a formatação da estruturação do código independente do editor ou IDE, como definição de indentação, charset, remoção de espaços em branco no final da linha e quebra de linha no final do arquivo.
Várias IDEs e editores disponibilizam um plugin nativo para configurar e aplicar o EditorConfig. Então, basta criar um arquivo com nome .editorconfig
na raiz do projeto, e logo adicionar as regras de formatação, como no exemplo abaixo:
Uma das peculiaridades do EditorConfig é permitir criar este arquivo de configurações em diretórios específicos. Com isso, precisamos utilizar a propriedade root = true
para definir qual é o arquivo principal de configurações.
Além disso, podemos definir propriedades de acordo com a extensão do arquivo. No exemplo, definimos a codificação de caracteres como charset = utf-8
para todos os arquivos, e configurações diferentes para arquivos que terminam com .ts e .tsx em relação a arquivos que terminam com .json.
Outras propriedades que podemos configurar são:
- indent_style: para definir o estilo de indentação do código;
- indent_size: para definir a quantidade de espaços ou tabulação da indentação;
- trim_trailing_whitespace: para definir se haverá remoção de espaços em branco no final da linha;
- insert_final_newline: para definir se haverá uma linha vazia no final do arquivo.
Mais sobre EditorConfig: https://editorconfig.org/
Prettier
O Prettier é um formatador de código automático, ou seja, ele garante que o código esteja formatado de acordo com as regras estabelecidas.
Ainda que essa ferramenta aceite um arquivo de configuração contendo as regras de formatação, ela pode ser configurada para trabalhar em conjunto com o ESLint. Para quem utiliza o editor VS Code, basta instalar o plugin Prettier – Code formatter e, no arquivo JSON de configuração do VS Code, adicionar as seguintes linhas:
Com isso, conseguimos integrar o Prettier para utilizar as regras de formatação estabelecidas no ESLint, além de aplicar essas regras automaticamente toda vez que salvamos o arquivo que contém o código.
Mais sobre Prettier: https://prettier.io/
Conclusão
O uso dos Style Guides deixam nossos projetos bem organizados e estruturados, facilitando a compreensão do código por todo o time de desenvolvimento ou até mesmo por outros programadores.
Com o uso de ferramentas que automatizam a aplicação desses guias, conseguimos melhorar nossa produtividade, além de possibilitar a obrigatoriedade dessas regras para todos que manipulam o código.
Autor: Igor Pimentel Gusmão Fragôso de Souza.
Comment (1)
"Code Smell": identificando problemas no código - Luby Software do seu jeito
[…] de não haver um padrão escrito, considera-se que 3 ou 4 parâmetros para uma função já estejam de bom tamanho. Ter muitos […]
Comments are closed.