Seguro que te has preguntado de quién es mejor el código: ¿un proyecto de código abierto o uno cerrado? Después de leer nuestro blog, podría pensar que todos los errores fueron recopilados por proyectos de código abierto. Pero no es así. Los errores están presentes en todos los proyectos, independientemente de cómo se almacenen. Y la calidad será mejor donde se mejore. Esta es una pequeña nota sobre cómo se corrigió un error en un proyecto durante 2 años, pero podría haberlo hecho en 5 minutos.
Cronología de eventos
Minetest es un motor de juego multiplataforma de código abierto que contiene aproximadamente 200.000 líneas de código C, C ++ y Lua. Te permite crear diferentes modos de juego en el espacio voxel. Admite multijugador y muchas modificaciones de la comunidad.
El 10 de noviembre de 2018, se abrió el número 7852 en el rastreador de errores del proyecto : item_image_button []: botón demasiado pequeño .
La descripción es la siguiente:
El botón es demasiado pequeño, lo que hace que la imagen exceda sus bordes. El botón debe tener el mismo tamaño que las ranuras de inventario. Vea el ejemplo a continuación (usando ancho y alto de 1).Y una captura de pantalla:
En la captura de pantalla, puede ver una ligera salida de imágenes fuera del borde del área interior de los botones. El error se notó en 2018, y la razón se encontró solo ahora, en 2020.
El siguiente evento en esta maravillosa historia fue la publicación del artículo técnico " PVS-Studio: Análisis de solicitudes de extracción en Azure DevOps usando agentes autohospedados " en julio de 2020 del año. Para dar un ejemplo de integración del analizador en Azure DevOps, se eligió el mismo juego: minetest. El artículo contiene varios errores encontrados, pero nos interesa uno específico:
V636La expresión 'rect.getHeight () / 16' se convirtió implícitamente del tipo 'int' al tipo 'float'. Considere utilizar un molde de tipo explícito para evitar la pérdida de una parte fraccionaria. Un ejemplo: doble A = (doble) (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);
}
Al dividir los valores de ancho y alto por 16, la parte fraccionaria del resultado se descarta, porque División entera.
Y ahora, seis meses después, los desarrolladores del juego notaron los resultados del análisis y se creó el Problema 10726 - Reparar errores encontrados por un analizador de código estático profesional , donde establecieron un vínculo entre este error y el Problema # 7852 . Este tamaño de botón redondeado y distorsionado.
conclusiones
El uso de analizadores de código estático le permite ahorrar mucho tiempo en la identificación de errores en su código. Se puede argumentar que el error descrito es insignificante, pero nuestra experiencia muestra que este es un ciclo de vida típico de un error de cualquier criticidad.
Digamos que hubo un error grave aquí. Habrían invertido todos sus esfuerzos en arreglarlo, y en una hora de depuración lo habrían encontrado y arreglado. Pero el analizador aún lo encontraría en un par de minutos.
Por tanto, podemos concluir que los métodos automáticos de búsqueda de errores aportan innegables beneficios al proyecto que se está desarrollando. Herramientas como PVS-Studio deben verse como una adición a la revisión de código con otros programadores, no como un reemplazo de este proceso.
Si desea compartir este artículo con una audiencia de habla inglesa, utilice el enlace de traducción: Svyatoslav Razmyslov. ¿Tuvo que tardar tanto en encontrar un error? ...