Certamente você se perguntou qual código é melhor: um projeto de código aberto ou fechado? Depois de ler nosso blog, você pode pensar que todos os bugs foram coletados por projetos de código aberto. Mas não é assim. Os erros estão presentes em todos os projetos, independentemente da forma como são armazenados. E a qualidade será melhor onde é melhorada. Esta é uma pequena nota sobre como um bug foi corrigido em um projeto por 2 anos, mas poderia ter feito isso em 5 minutos.
Cronologia dos eventos
Minetest é um mecanismo de jogo de plataforma cruzada de código aberto contendo cerca de 200.000 linhas de código C, C ++ e Lua. Ele permite que você crie diferentes modos de jogo no espaço voxel. Suporta multijogador e muitos mods de comunidade.
Em 10 de novembro de 2018, a edição nº 7852 foi aberta no rastreador de bug do projeto - item_image_button []: botão muito pequeno .
A descrição é a seguinte:
O botão é muito pequeno, resultando em imagem excedendo suas bordas. O botão deve ter o mesmo tamanho dos slots de inventário. Veja o exemplo abaixo (usando largura e altura de 1).E uma captura de tela:
Na captura de tela, você pode ver um leve fluxo de imagens fora da borda da área interna dos botões. O bug foi detectado em 2018, e o motivo foi descoberto apenas agora - em 2020.
O próximo evento nesta história maravilhosa foi a publicação do artigo técnico " PVS-Studio: Análise de solicitações pull no Azure DevOps usando agentes auto-hospedados " em julho de 2020 Do ano. Para dar um exemplo de integração do analisador no Azure DevOps, o mesmo jogo foi escolhido - mineteste. O artigo contém vários erros encontrados, mas estamos interessados em um específico:
V636A expressão 'rect.getHeight () / 16' foi convertida implicitamente do tipo 'int' para o tipo 'float'. Considere a utilização de um tipo explícito de fundição para evitar a perda de uma parte fracionária. Um exemplo: double A = (double) (X) / Y;. hud.cpp 771
void drawItemStack(....)
{
float barheight = rect.getHeight() / 16;
float barpad_x = rect.getWidth() / 16;
float barpad_y = rect.getHeight() / 16;
core::rect<s32> progressrect(
rect.UpperLeftCorner.X + barpad_x,
rect.LowerRightCorner.Y - barpad_y - barheight,
rect.LowerRightCorner.X - barpad_x,
rect.LowerRightCorner.Y - barpad_y);
}
Ao dividir os valores de largura e altura por 16, a parte fracionária do resultado é descartada, porque divisão inteira.
E agora, seis meses depois, os resultados da análise foram notados pelos desenvolvedores do jogo, e foi criado o Problema 10726 - Corrigir erros encontrados por analisador de código estático profissional , onde eles estabeleceram uma conexão entre este bug e o Problema # 7852 . Este tamanho de botão arredondado e distorcido.
conclusões
Usar analisadores de código estáticos permite que você economize muito tempo na identificação de erros em seu código. Pode-se argumentar que o bug descrito é insignificante, mas nossa experiência mostra que este é um ciclo de vida típico de um erro de qualquer criticidade.
Digamos que houve um bug sério aqui. Teríamos investido todos os nossos esforços para consertá-lo e, em uma hora de depuração, o teríamos encontrado e consertado. Mas o analisador ainda o encontraria em alguns minutos.
Assim, podemos concluir que métodos automáticos de localização de erros trazem benefícios inegáveis ao projeto em desenvolvimento. Ferramentas como o PVS-Studio devem ser vistas como um acréscimo ao codereview com outros programadores, não uma substituição para este processo.
Se você deseja compartilhar este artigo com um público falante de inglês, use o link de tradução: Svyatoslav Razmyslov. Foi preciso tanto tempo para encontrar um bug? ...