Blog (Português)

cada vez mais equipes adotaram linters e outras ferramentas estáticas em seu processo de desenvolvimento. Alguns integraram-nos na IDE da sua preferência, outros automatizados executando-os como um passo adicional na sua IC. Além disso, alguns correm para os dois lados.o que é um linter, então?

de acordo com o Wikipedia, linter

é uma ferramenta que analisa o código fonte para erros de programação da bandeira, bugs, erros estilísticos e construções suspeitas.,

o primeiro linter foi escrito por Stephen C. Johnson em 1978 enquanto trabalhava no sistema operacional Unix em Bell Labs. Depois disso, muitos outros linters têm aparecido para diferentes propósitos e linguagens, não apenas C.

os primeiros linters usados para verificar o código fonte e encontrar potenciais otimizações para compiladores. Mas, ao longo dos anos, muitas outras verificações e análises seriam incluídas no processo de linting.

o uso de linters também ajudou muitos desenvolvedores a escrever um código melhor para linguagens de programação não compiladas., Como não há erros de tempo de compilação, encontrar erros de sintaxe, uso de variáveis não declaradas, chamadas para funções indefinidas ou desactualizadas, por exemplo, ajudando os desenvolvedores a corrigi-lo mais rápido e reduzir bugs antes da execução.

os Linters evoluíram

os Linters evoluíram. Eles começaram com esses simples cheques, mas hoje em dia, eles estão ficando cada vez mais sofisticados. Eles realizam análises estáticas, impõem bandeiras de configuração, verificam a conformidade com um determinado guia de estilo ou regra de segurança, e muito mais.,vamos explorar algumas dessas verificações e como elas podem ser úteis para você.

análise estática

análise estática significa que o software automatizado corre através da sua fonte de código sem executá-lo. Ele verifica estaticamente possíveis bugs, vazamentos de memória, e qualquer outra verificação que possa ser útil.

Se você é um desenvolvedor Python, você já pode conhecer o Radon. Ele pode contar as linhas de código fonte (SLOC), linhas de comentário, uma linha em branco, e outras métricas raw, mas também, ele pode calcular um “índice de manutenção”, que pode ser muito importante em alguns projetos.isso é apenas um exemplo., Existem muitos outros linters que realizam verificações de análise estática.

E-book gratuito: Clique aqui para baixar a revisão de código de descodificação e puxar os Pedidos. Obtenha todos os pontos-chave e melhores práticas para implementar uma cultura de revisão de código.

Código de padronização

De https://xkcd.com/1285/

a Padronização do seu código é uma ótima maneira de mover a conversa para um mais produtivo nível., Ter um diretório e rodando linters contra a base de código evita alterações estéticas em seu pedido de pull, como substituir todas as abas por espaços, indentando uma atribuição variável, ou até mesmo quebras de linha após um dado número de caracteres.a maximização de mudanças significativas leva a sua discussão para tópicos que importam, como decisões arquitetônicas, questões de segurança ou bugs potenciais.

A propósito, problemas de segurança e bugs potenciais também podem ser evitados por linters!

questões de segurança

Se você está em trilhos, você provavelmente já ouviu falar sobre Brakeman., É uma ferramenta de segurança de análise estática. É benéfico encontrar potenciais problemas de segurança. Por exemplo, ele executa verificações à procura de injeção de SQL ao usar o #find_or_create_by e amigos. Ele também adiciona verificações para XSS, opções de configuração, e muito mais.

Ruby não é a única linguagem com este tipo de motor. O SourceLevel suporta muitos motores para diferentes idiomas. Incluindo o Brakeman.JavaScript tem alguns truques. Um dos mais famosos é a diferença entre ==e===., É uma boa prática, e evita muito tempo de depuração, para sempre usar ===. Se você habilitar, por exemplo, o ESLint para verificar isso, ele pode dizer-lhe qual parte do seu código está usando == e até mesmo substituí-lo para você.

melhorias de desempenho

cada desenvolvedor experiente sabe não só a importância de executar software, mas muitos truques que o melhoram. O problema é: e os recém-chegados? Como você pode passar este conhecimento para a frente? Até os programadores seniores podem perder uma ou duas técnicas. Então, por que não deixar um software de automação fazê-lo por você?,sabia que em CSS, o selector universal (*) pode atrasar o tempo de carregamento de uma página? Ou que os selectores de atributos não qualificados têm as mesmas características de desempenho que o selector universal? Evitá-los é uma boa prática.

muitos linters incluem uma verificação de desempenho. Eles podem adicionar diferentes tipos de melhorias de desempenho para desenvolvedores experientes e recém-chegados. CSSLint é apenas um exemplo.

e muitos outros aspectos

até ao infinito e além!, Há muitos e muitos linters para diferentes linguagens de programação, arquivos de configuração, e até mesmo para integrações de software. Qualquer verificação que seja importante e possa ser automatizada pode transformar-se em um linter.

Se você trabalha em um cenário particular, você pode ter que escrever o seu linter, mesmo que não seja muito provável em nossa indústria. Verifica os recursos de acessibilidade HTML, erros potenciais de internalização, erros de gramática, e muitos outros já estão lá, open-sourced, esperando por você para baixar, configurar e começar a usar.de acordo com Ferit T.,, linting melhora a legibilidade, remove erros tolos antes da execução e revisão de código. Mas, como mencionado, linting pode fazer trabalhos mais complexos, como detectar cheiros de código ou realizar análises estáticas de sua base de código.

mas, na prática, quais são as vantagens de linting?

melhora o nível de discussão de revisão de código

Se o seu pedido de puxar não tem erros de Digitação, nem variáveis não utilizadas, e está em conformidade com o Guia de estilo, a conversa tende a concentrar-se no ponto de vista da arquitectura. É isso., O pedido Pull é um ótimo lugar para apontar questões de desempenho, vulnerabilidades de títulos, ou sugerir melhores abstrações. Você não precisa entrar nessa discussão de aspas simples ou duplas ou tab vs. espaços. É um ganho de produtividade, com certeza.

faz o código parecer escrito por uma única pessoa

a médio e longo prazo, tendo uma base de código confiável que parece escrito pela mesma pessoa é excelente. A manutenção e evolução são mais fáceis porque todos tendem a entender o que está escrito mais rápido e mais preciso., Evita erros, torna o trabalho mais alegre para os desenvolvedores, e acelera o tempo para o mercado de novos recursos.

dá visibilidade à sua saúde na base de código

o seu código é saudável? Só saberás quando o medires. Uma maneira emocionante de fazê-lo é adicionar um passo em seu pipeline CI/CD para medir a evolução do seu estado de saúde código. Melhor do que isso, você pode tomar medidas o mais rápido possível quando você vê a sua saúde para decair., Tais ações podem implicar na criação de cartões de débito técnicos em sua placa ou até mesmo levantar a questão durante a sua ágil retrospectiva ou reunião do Comitê de arquitetura.

spreads conscientização e propriedade sobre a qualidade do Código

desenvolvedores experientes podem olhar para uma diferença e levantar questões relevantes sobre a mudança proposta. Eles provavelmente sabem onde procurar: variáveis são descritivos de nomes? Quantas linhas um método leva? Há alguma super classe?mas e os recém-chegados? O conhecimento em uma equipe é muitas vezes heterogêneo. Significa que nem todos os programadores sabem o que ver o código., Ter um linter para dizer onde cheiros de código são automaticamente é uma excelente maneira de espalhar este conhecimento e fazer a equipe responsável pelas mudanças.a qualidade não é uma responsabilidade individual. É essencial medir e controlar a qualidade do Código ao longo do tempo. Caso contrário, o código fica confuso, o que atrasa o desenvolvimento e o tempo para o mercado.,

Controles técnicos dívidas

Como muitos modernos “linters” olhar para as técnicas possíveis dívidas, como o código de cheiros, guia de estilo inadequações, ou mal projetada código (deep cadeias de if declarações, ou complexo demais métodos, por exemplo), “linters” correlaciona-se com dívida técnica.

tornando as dívidas técnicas explícitas durante o processo de revisão de código ajudar os desenvolvedores de software ou engenheiros a localizá-lo, discutir e corrigi-lo antes da fusão no ID