Linters

Boas práticas não se sustentam apenas por boa vontade. Em equipes reais, é preciso transformar convenções em regras observáveis e repetíveis. É nesse ponto que entram style guides, linters e formatadores: eles reduzem ambiguidade, automatizam consistência e liberam pessoas para discutir arquitetura, domínio e qualidade real do código.

Estilo como acordo de equipe

Todo time precisa de um padrão de escrita. Sem isso, cada arquivo reflete preferências individuais sobre indentação, aspas, nomes, imports, espaçamento e organização estrutural. O resultado é um repositório visualmente inconsistente, mais cansativo de ler e revisar.

Padronização traz ganhos concretos:

• menos discussão subjetiva em pull requests;
• menor atrito entre pessoas e times;
• leitura mais rápida de código desconhecido;
• histórico de commits mais limpo, com menos diffs cosméticos.

Style guides

Style guides são documentos opinativos que definem convenções do projeto ou da comunidade. Eles descrevem como a equipe prefere organizar e escrever código.

Um style guide útil costuma cobrir:

• convenções de nomenclatura;
• organização de arquivos e imports;
• regras de formatação;
• práticas específicas da linguagem;
• exceções aceitáveis ao padrão.

Sem documentação, o time depende de memória coletiva. Com documentação, o padrão fica ensinável, revisável e automatizável.

O que são linters

Linters analisam código-fonte em busca de problemas. Dependendo da ferramenta, eles detectam:

• violações de estilo;
• inconsistências de formatação;
• construções propensas a bug;
• más práticas conhecidas;
• code smells simples;
• oportunidades de padronização.

Eles não substituem revisão humana, mas funcionam como primeira barreira de qualidade.

Tipos de linters

Linters de estilo

Focam forma e consistência visual:

• espaçamento;
• indentação;
• tamanho de linha;
• aspas;
• ponto e vírgula;
• convenções de nomenclatura.

Exemplo: parte do que ESLint ou RuboCop pode validar, dependendo da configuração.

Linters de qualidade

Focam padrões associados a defeitos ou manutenção ruim:

• variáveis não utilizadas;
• código inalcançável;
• comparação problemática;
• duplicação simples;
• complexidade excessiva;
• APIs obsoletas ou arriscadas.

Ferramentas mais robustas, como SonarLint, ampliam esse tipo de análise.

Linter vs formatter

Embora às vezes atuem juntos, não são exatamente a mesma coisa.

• formatter: reescreve o código para um formato padronizado;
• linter: analisa e sinaliza problemas segundo regras configuradas.

Na prática, ferramentas podem se complementar. Exemplo comum no ecossistema JavaScript:

• Prettier cuida da forma automática;
• ESLint cuida de estilo, consistência e algumas regras de qualidade.

Essa combinação diminui discussões manuais e deixa revisões mais objetivas.

Integração com IDE

O melhor momento para descobrir problema de estilo ou regra simples é antes do commit. Por isso, integrar linter ao editor/IDE gera retorno imediato e reduz retrabalho.

Benefícios:

• feedback rápido;
• correção no contexto em que o código está sendo escrito;
• aprendizado contínuo da equipe;
• menos surpresa na pipeline.

Quando a pessoa enxerga o aviso na hora, o custo de correção é mínimo.

Integração com CI/CD

Linters também devem rodar na pipeline. Isso garante que o padrão não dependa do ambiente local de cada pessoa.

Na CI, o linter ajuda a:

• bloquear código fora do padrão;
• impedir regressões simples;
• dar previsibilidade ao repositório;
• reforçar qualidade mínima antes de merge/deploy.

Uma boa prática é tratar regras críticas como erro e regras pedagógicas ou de transição como aviso, conforme maturidade do time.

Ferramentas populares

Alguns exemplos citados nos slides:

• ESLint: JavaScript/TypeScript
• Prettier: formatação para JavaScript e outros ecossistemas
• Flake8: Python
• Black: formatter para Python
• RuboCop: Ruby
• PHPStan: PHP
• SonarLint: múltiplas linguagens, com foco em qualidade
• Checkstyle: Java
• Clang-Tidy: C/C++

A escolha depende da linguagem, do stack e do nível de rigor desejado.

Regras personalizadas e contexto do projeto

Nem toda regra de uma comunidade serve para todo projeto. Times maduros adaptam ferramentas à realidade local:

• limite de linha compatível com o código-base;
• convenções específicas de framework;
• regras relaxadas para código legado;
• políticas mais rígidas em módulos críticos.

O perigo está em cair em dois extremos:

• poucas regras, que não geram padrão real;
• regras demais, que tornam a ferramenta irritante e ignorada.

Linters como apoio pedagógico

Em contexto acadêmico ou de formação, linters têm um papel extra: ensinar hábito. Eles ajudam estudantes a perceber padrões de erro recorrentes e a construir consistência sem depender apenas de correção manual do professor.

Exemplos de aprendizado favorecido:

• perceber impacto de variáveis não usadas;
• respeitar identação e convenções;
• identificar construções confusas;
• ganhar disciplina com feedback imediato.

Limites dos linters

Linters são valiosos, mas não resolvem tudo. Eles não entendem plenamente:

• modelagem de domínio;
• adequação arquitetural;
• clareza pedagógica de exemplos;
• decisões de produto;
• sutilezas de design.

Um código pode passar em todas as regras automáticas e ainda assim ser confuso ou mal projetado. Por isso, linter complementa revisão técnica; não substitui leitura crítica.

Como adotar bem em equipe

Uma adoção saudável geralmente segue este caminho:

1. definir style guide ou herdar um padrão reconhecido;
2. configurar formatter automático;
3. ativar linter localmente e na CI;
4. começar com regras de maior valor e menor atrito;
5. revisar periodicamente as regras que geram ruído;
6. documentar exceções justificadas.

Quando o conjunto de ferramentas é bem ajustado, ele deixa de ser obstáculo e passa a ser parte natural do fluxo de desenvolvimento.

Checklist prático

Ao avaliar uso de linter no projeto, pergunte:

• existe um style guide explícito?
• formatter e linter estão integrados ao editor?
• a pipeline aplica as mesmas regras do ambiente local?
• as regras refletem problemas reais do time?
• há equilíbrio entre estilo e qualidade?
• a ferramenta ajuda a equipe ou virou fonte constante de ruído?