Quais são os reais benefícios da análise de código estático?

Ferramentas como pc-lint ou QAC podem ser usadas para executar análise de código estático em uma base de código.

Na minha experiência, a análise estática geralmente gera uma quantidade enorme de ruído, ou seja, avisos sobre coisas que não são erros reais, mas de alguma forma violam uma das regras em um determinado conjunto de regras. Desativar certas regras (para sempre no conjunto de regras ou através de comentários especiais no código) pode ser um processo realmente complicado.

Quais são os reais benefícios da análise de código estático?

Eu trabalhei em um local que usava um sistema comercial de análise de código estático chamado Coverity Prevent, e era incrível! É realmente sofisticado e inteligente.

Jogamos cerca de 18 GB de código C e C ++ de código-fonte aberto e proprietário nele, e ele rastreava os caminhos do código e encontrava rapidamente erros sutis que levariam um ser humano para sempre a rastrear. Também foi ótimo em identificar coisas que geralmente seriam Heisenbugs.

Ele funcionava a cada poucos dias em nossa base de código, e um recurso interessante era que poderíamos dizer: "Isso não é realmente um bug", e lembraria disso no futuro.

O problema é que a cobertura é realmente cara. Eles não publicam os custos, mas sinto que, para projetos comerciais, isso começa nas centenas de milhares de dólares por ano. Mas isso provavelmente nos impediu de contratar um monte de desenvolvedores e equipe de controle de qualidade; portanto, em geral, nossa gerência parecia pensar que era uma boa compra.

Tendo tido essa experiência, considero bastante favorável a análise de código estático.

Ao começar com um novo idioma, é bom ter um treinador. É assim que penso nas ferramentas de análise estática. Eu escrevo muito javascript e, no começo, peguei alguns maus hábitos, principalmente porque estava transferindo algumas coisas de idiomas anteriores. O Javascript é bastante flexível, então você pode se safar de praticamente qualquer coisa, mas se eu tivesse o jslint me alertando sobre certos padrões, teria escolhido melhores padrões de codificação desde o início, em vez de ter que reaprender coisas mais tarde.

Analisadores estáticos são basicamente revisões de código assistidas por máquina. Eles apontam áreas questionáveis ​​que podem ser perdidas durante os testes regulares.

Por exemplo, o autor realmente quis fazer uma tarefa neste condicional?

if (x = 1) {
    ...
}

Ou talvez um novato confunda elenco lexical:

char* number = "123";
int converted = number;

Certamente, os analisadores estáticos requerem ajustes. Por outro lado, o controle de revisão, wikis, rastreadores de bugs, impressoras bonitas e outras ferramentas também requerem algumas configurações. Quanto maior o projeto, melhor a recompensa pelo trabalho inicial.

Do ponto de vista de um consultor, toda ferramenta de análise estática terá algum ruído, mas nem todos os analisadores estáticos são criados iguais. Ferramentas de análise estática como Coverity, Klocwork, Grammatech têm boas técnicas de análise que devem produzir resultados mais precisos. Se você ajustar e ajustar um pouco mais, obterá melhores resultados normalmente (afinal de contas, os analisadores estáticos precisam ser capazes de executar todos os tipos diferentes de código, de um minúsculo dispositivo médico a um sistema operacional de rede). A definição de "ruído" também depende de seus critérios para o que constitui um relatório com correção. Em uma extremidade do espectro, alguns desenvolvedores marcam todos os relatórios que eles não corrigem como "falsos" (até mesmo códigos mal escritos que eles não têm tempo para corrigir) e, por outro lado,

Algumas dessas ferramentas são mais focadas na análise central e outras são mais focadas na área de trabalho - embora todas as três tenham recursos compatíveis com ambas. Como o @Bob mencionou, eles custam dinheiro.

Na minha empresa anterior, usamos o analisador estático da Parasoft. E acreditava-se dentro da equipe que pelo menos 60% dos erros em tempo de execução foram detectados antes da compilação.

A análise estática também pode ser realizada sem ferramentas, executando revisões manuais no código do software. Geralmente, é a maneira mais econômica de melhorar a qualidade do código.

A segunda melhor opção é investir em uma ou mais ferramentas de análise estática de ponta (como o Coverity mencionado anteriormente, ou KLOCwork). Como essas ferramentas realizam análises muito mais profundas que o fiapo, por exemplo, a relação sinal / ruído é muito melhor.

Considero usar o fiapo como terceira opção, devido ao alto nível de ruído. Aplicar fiapos a um projeto existente pode ser uma tarefa assustadora.

Em geral, a análise estática de programas progrediu muito nos últimos anos. As atuais ferramentas de análise estática são capazes de realizar análises interprocedimentais profundas, e podem identificar automaticamente, por exemplo, procedimentos pré e pós-condições. Essa também pode ser uma grande ajuda para revisões posteriores de código.

Devido à alta taxa de falsos positivos, você não deve usar uma ferramenta de análise estática (como lint ou FindBugs) para cada compilação.

Em vez disso, é uma boa verificação de sanidade para consultar uma vez que você tenha um bug e não consegue descobrir . Nesse caso, você pode receber os falsos positivos e já pode ter reduzido as possíveis fontes do erro. Por exemplo, se você reproduzir seu erro sem sequer executar algum módulo, poderá ignorar o que o FindBugs diz para eles. Isso é particularmente útil quando você olha para um trecho de código e pensa que ele diz uma coisa, enquanto o compilador o lê literalmente (como em Java quando você tem um equalsmétodo que aceita o tipo de classe em vez de Object).

Você também pode fazer com que as ferramentas de análise estática façam parte do seu processo de desenvolvimento: quando um desenvolvedor recebe uma revisão de código, ele também deve executar o FindBugs nele. Em resumo, é útil, mas você não o utilizará com a mesma frequência que o compilador ou o editor de texto.