lint, ou linter, é um software originalmente desenvolvido em 1978 com o intuito de apontar, através de análise estática do código, falhas que pudessem levar a problemas no software. Originalmente disponível somente para linguagem C, hoje em dia é sinônimo de analizador estático de código para qualquer linguagem.

C e C++

Infelizmente as versões originais do lint não são compatíveis com as versões atuais das linguagem C e C++. Atualmente existem diversos lints disponíveis, alguns deles softwares livres, como cppcheck, sparse ou splint; outros embutidos em IDEs ou compiladores, com CLang, Eclipse ou VisualStudio.

De qualquer forma, o mais indicado é ter mais de uma ferramenta para validar a qualidade do código, cada ferramenta utiliza uma técnica para detectar as falhas, é perfeitamente plausível uma falha não ser apontada por uma ferramenta e ser apontada por outra.

Dentre as diversas falhas normalmente detectadas por lints podemos listar algumas bem perigosas, tais como ponteiros para variáveis locais, buffer overflow, inicialização de variáveis, utilização de ponteiros nulos ou inválidos, condições inválidas ou sempre verdadeira/falsa, utilização de recursos liberados, vazamento de memória, variáveis e funções não utilizadas, dentre diversas outras.

Integração Contínua

Nos últimos 10 anos a utilização de lints tem se tornado cada vez mais comum, conforme a popularidade da integração contínua vai crescendo. Seu uso recente mais comum é barrar commits, ou pushes, de código que adicionem falhas de lint; ou então somente fazer deploy de código que não contenham falhas de lint.

Essa prática garante builds muito mais estáveis e seguros, tratando as falhas em potencial diretamente na fonte do problema.

Argumentando em Prol da Qualidade do Código

Nem sempre o time já utiliza lints para gerir a qualidade de código, e implantar uma ferramenta assim pode gerar problemas dentro de uma equipe. Muitas vezes os desenvolvedores tem receio de verem falhas e vícios apontadas, outras acreditam que é mais um trabalho inútil que não vai acrescentar muito. Para resolver estes problemas é preciso argumentar.

O primeiro argumento para investir em cuidados com a qualidade de código sempre é o custo de manutenção. Um código que falha menos custa menos para ser mantido.

Além disso o tipo de falha detectada por lints C e C++ é, na maioria das vezes, de difícil reprodução, e consequentemente necessita de profissionais mais caros para resolvê-los.

Para finalizar, ao incrementar a qualidade do código, o nível de falhas irá consequentemente reduzir, liberando o time para investir em novas funcionalidades, aumentando a satisfação dos clientes, e melhorando a visibilidade do time.

Implantando

A situação ideal é sempre utilizar o lint, desde o início do projeto, e manter o nível de falhas, ou de warnings, em zero. Mas nem sempre isso é possível. Muitas vezes os processos de desenvolvimento já estão estabelecidos, e uma caça às falhas pode ser visto com péssimos olhos pelo time, ou mesmo pela liderança.

Portanto o ideal é utilizar de argumentos, principalmente o de custos, para implantar a análise estática de código gradualmente. Inicialmente através da não inserção de novas falhas, e posteriormente com a eliminação gradual das falhas e em seguida dos warnings. E para isso é essencial o patrocínio da liderança para exigir aderência aos novos parâmetros.

Manutenção

Uma vez implantada a política de zero falhas é possível implantar o lint diretamente no sistema de gestão de versão, git, svn ou equivalente. Proibindo a publicação de código que contenha falhas de lint.

Nesse ponto as técnicas de integração contínua além de auxiliar na manutenção do nível de falhas aumenta a visibilidade da solução, uma vez que integração contínua é uma das buzzwords do momento.

Tags: análise estática, qualidade