De vez em quando, programadores que começam a se familiarizar com o analisador de código PVS-Studio me perguntam: "Existe uma lista de avisos que indicam com precisão erros?" Não existe essa lista porque os avisos (falsos) desinteressantes em um projeto são muito importantes e úteis em outro. No entanto, pode-se começar a cavar o analisador com os avisos mais emocionantes. Vamos dar uma olhada mais de perto neste tópico.
O problema é que, regra geral, a princípio, um programador se afoga em um grande número de avisos que recebe. Naturalmente, ele quer começar a revisar os avisos mais interessantes para entender se deve gastar seu tempo resolvendo tudo isso. Bom, então aqui estão três etapas simples que permitirão que ele verifique os avisos mais emocionantes.
Etapa 1
Desative todos os tipos de avisos, exceto os gerais (GA). Um erro comum é ativar todos os tipos de avisos. Usuários inexperientes pensam que quanto mais habilitar, melhor. Esse não é o caso. Existem conjuntos de diagnóstico, como verificações de 64 bits e regras MISRA, que devem ser usados apenas quando se sabe claramente o que são e como trabalhar com eles. Por exemplo, habilitando o diagnóstico MISRA para um programa de aplicativo comum, você se afogará em dezenas, milhares ou centenas de milhares de avisos, como:
- V2506 . Misra. Uma função deve ter um único ponto de saída no final.
- V2507 . Misra. O corpo de uma instrução loop \ condicional deve ser colocado entre chaves.
- V2523 . Misra. Todas as constantes inteiras do tipo não assinado devem ter o sufixo 'u' ou 'U'.
A maioria dos avisos MISRA indica não erros, mas o cheiro do código. Naturalmente, um programador começa a fazer perguntas. Como você encontra algo interessante na pilha de todos esses avisos? Que números ele deveria assistir? Estas são as perguntas erradas. Você só precisa desativar o conjunto MISRA. Esse é o padrão para escrever código de qualidade para dispositivos incorporados. O objetivo do padrão é tornar o código extremamente simples e compreensível. Não tente aplicá-lo onde for inapropriado.
Nota Sim, o MISRA possui regras projetadas para identificar erros reais. Exemplo:
V2538 - O valor da variável não inicializada não deve ser usado. Mas não tenha medo de desativar o padrão MISRA. Você não vai perder nada. Os erros reais ainda serão encontrados como parte do Diagnóstico Geral (GA). Por exemplo, uma variável não inicializada será encontrada pelo diagnóstico
V614 .
Etapa 2
Qualquer analisador estático emite falsos positivos nas primeiras execuções e requer alguma configuração. Nada pode ser feito sobre isso, mas não é tão assustador quanto possa parecer. Mesmo uma configuração rápida simples permite remover a maioria dos falsos positivos e começar a exibir um relatório bastante relevante. Não falarei mais sobre isso, como já escrevi sobre isso muitas vezes, por exemplo, neste artigo: "
Características do PVS-Studio Analyzer pelo exemplo das bibliotecas principais da EFL, 10 a 15% dos falsos positivos ".
Gaste um pouco de tempo desativando avisos obviamente irrelevantes e lutando contra falsos positivos relacionados a macros. De um modo geral, as macros são o principal motivo de falsos positivos, pois um aviso aparece em todos os casos quando uma macro mal implementada é usada. Para suprimir avisos em macros, você pode escrever comentários de um tipo especial ao lado da declaração. O formato de mais comentários é abordado na
documentação .
Sim, a configuração inicial levará um pouco de tempo, mas melhorará drasticamente a percepção do relatório, eliminando o ruído perturbador. Tire algum tempo para fazê-lo. Se houver alguma dificuldade ou dúvida, estamos sempre prontos para ajudá-lo e informar como configurar o analisador da melhor maneira. Sinta-se livre para
escrever e fazer perguntas.
Etapa 3
Comece a ver avisos do nível 1. Somente depois de assistir 2 e 3. Os níveis de aviso nada mais são do que a veracidade de um aviso. Os avisos do nível 1 são mais propensos a indicar um erro real do que os avisos do nível 2.
Você pode dizer que, quando escolhe "assistir ao nível 1", pressiona o botão "assistir aos erros mais interessantes".
Mais detalhadamente, a classificação dos avisos do PVS-Studio por níveis é descrita no artigo "
A maneira como os analisadores estáticos combatem os falsos positivos e por que eles fazem isso ".
Então, por que não há uma lista?
No entanto, a ideia de ter uma lista dos avisos mais úteis ainda pode parecer razoável. Deixe-me mostrar em um exemplo prático que a utilidade de um diagnóstico é relativa e depende do projeto.
Vamos considerar o aviso da
V550 . O aviso detecta um erro potencial relacionado ao fato de que, para comparar números com um ponto flutuante, os operadores == ou! = São usados.
A maioria dos desenvolvedores com quem conversei acha que esse diagnóstico é inútil e o desabilita porque todos os disparos para o projeto são falsos. É por isso que esse diagnóstico tem baixo nível de certeza e se relaciona com o nível 3.
De fato, na maioria das aplicações, os tipos float / double são usados em algoritmos muito simples. Freqüentemente, a comparação com a constante é usada apenas para verificar se um determinado valor está definido por padrão ou se ele foi alterado. Nesse caso, a verificação exata é bastante apropriada. Vou explicar com pseudo-código.
float value = 1.0f; if (IsUserInputNewValue()) value = GetUserValue(); if (value == 1.0f) DefaultBehavior(); else Foo(value);
Aqui a comparação
(valor de 1.0f) é correta e segura.
Isso significa que o diagnóstico do V550 é desinteressante? Não. Tudo depende do projeto. Deixe-me citar um trecho do artigo "
Como tentamos a análise estática em nosso projeto de simulador de treinamento em cirurgia endovascular de raio-x ", escrito por nosso usuário.
Então, o que nosso analisador estático presta atenção aqui:
V550 Uma comparação precisa e estranha: t! = 0. Provavelmente é melhor usar uma comparação com precisão definida: fabs (A - B)> Epsilon. objectextractpart.cpp 3401
D3DXVECTOR3 N = VectorMultiplication( VectorMultiplication(V-VP, VN), VN); float t = Qsqrt(Scalar(N, N)); if (t!=0) { N/=t; V = V - N * DistPointToSurface(V, VP, N); }
Erros desse tipo se repetem com frequência nesta biblioteca. Não posso dizer que foi uma surpresa para mim. Anteriormente, encontrei manipulação incorreta de números com um ponto flutuante neste projeto. No entanto, não havia recursos para verificar sistematicamente as fontes. Como resultado da verificação, ficou claro que era necessário fornecer ao desenvolvedor algo para ampliar seus horizontes em termos de trabalhar com números de ponto flutuante. Ele foi vinculado a alguns bons artigos. Vamos ver como as coisas acabam. É difícil dizer com certeza se esse erro causa interrupções reais no programa. A solução atual expõe vários requisitos para a malha poligonal original das artérias, que simula a propagação da matéria de contraste de raios-X. Se os requisitos não forem atendidos, o programa pode falhar ou o trabalho está claramente incorreto. Alguns desses requisitos são obtidos analiticamente e outros - empiricamente. É possível que esse conjunto empírico de requisitos esteja crescendo apenas devido ao tratamento incorreto de números com um ponto flutuante. Note-se que nem todos os casos encontrados de comparação precisa de números com ponto flutuante foram um erro.
Como você pode ver, o que não é interessante em alguns projetos é interessante em outros. Isso torna impossível criar uma lista dos "mais interessantes".
Nota Você também pode definir o nível de avisos usando as configurações. Por exemplo, se você acha que o diagnóstico do V550 merece muita atenção, é possível movê-lo do nível 3 para o 1. Esse tipo de configuração é descrito na
documentação (consulte "Como definir seu nível para diagnósticos específicos").
Conclusão
Agora você sabe como começar a estudar os avisos do analisador, observando os mais interessantes. E não se esqueça de consultar a documentação para obter uma descrição detalhada dos avisos. Às vezes acontece que por trás de um aviso indefinido, à primeira vista, o aviso está no inferno. Um exemplo desses diagnósticos:
V597 ,
V1026 . Obrigado pela atenção.