John Carmack om statisk kodanalys

Programmeraren John Carmack, skaparen av Doom, Quake m.m. har skrivit en mycket läsvärd text om användning av statisk kodanalys för att hitta fel.

John Carmack

John Camrack hackandes Doom.

Att använda statisk kodanalys som del av utvecklingsmetodiken fångar semantiska fel som är svåra eller omöjliga att hitta med kodgranskning, enhetstester eller dynamisk kodanalys, exempelvis minnesövervakning och fuzzing. Vidare, vilket Carmack påpekar, går det inte att undvika att det introduceras fel, oavsett vilka kodregler som skall följas. Speciellt i en stor, levande kodbas kan förutsättningar ändras som gör att fungerande kod påverkas. John Carmack skriver:

A lot of the serious reported errors are due to modifications of code long after it was written.  An incredibly common error pattern is to have some perfectly good code that checks for NULL before doing an operation, but a later code modification changes it so that the pointer is used again without checking.  Examined in isolation, this is a comment on code path complexity, but when you look back at the history, it is clear that it was more a failure to communicate preconditions clearly to the programmer modifying the code.

John tar upp flera exempel på problem där statisk kodanalys hjälpt ID Software att hitta buggar. De två vanligaste buggarna ID Software hittat är hantering av NULL-pekare i C/C++ samt print-formatteringsfel.

Carmack har även testat flera olika verktyg (Coverity, MS/Analyze, PVS-Studio, PC-Lint) och det visar sig att det skiljer mycket vad gäller mängden och typen av buggar olika verktyg hittar. En aspekt på detta, vilket är ett vanligt problem med denna typ av verktyg är att dom ofta genererar stora mängder med varningar, vilket gör det svårt för konstruktören att hitta de viktiga felen och förstå vad som är problemet. Bra verktyg ska inte bara hitta många fel, utan även kunna gradera dom och hjälpa konstruktören till en bra lösning. Inte minst om kodanalys introduceras i en existerande kodbas kan mängden varningar lätt bli övermäktigt. Carmack påpekar att detta var ett problem första gången han försökte använda denna typ av verktyg, men att verktygen förbättrats.

Jag använder det analysverktyg som finns för kompilatorsystemet clang/llvm. Jag tycker att den fångar många buggar och illustrerar dessa på ett relativt bra sätt. Men graderingen av hur allvarlig en bugg är kan helt klart förbättras.

Bild på rapport från clangs analys.
Bild på rapport från clangs analys.

Carmacks slutsats är att statisk kodanalys är ett viktigt tillägg till utvecklingsmetodiken:

It is impossible to do a true control test in software development, but I feel the success that we have had with code analysis has been clear enough that I will say plainly it is irresponsible to not use it.

För den som vill titta närmare på statisk kodanalys har Wikipedia en bra lista med verktyg.

2 reaktioner på ”John Carmack om statisk kodanalys

  1. Eller så kan man använda ett språk där ”NULL-pekare i C/C++ samt print-formatteringsfel” inte är ett problem :-)

    1. Visst är byte av språk och exekveringsmiljö ett sätt att bli av med dessa fel. Men ofta är det inte ett alternativ. Typiska skäl är:
      * Kompetens hos utvecklare, uppdragsgivare, företag
      * Befintlig kodbas, kodmiljö, verktyg
      * Målmiljö
      * Applikationskrav – begränsningar och prestanda

      Vidare var detta de mest frekventa felen Carmack & Co hittade. Min erfarenhet är att statisk kodanalys snarare är än viktigare vad gäller att hitta semantiska sidofall som annars tar lång tid att hitta med fuzzing eller omöjliga att gr0kka som människa. Speciellt i protokollimplemntationer har statisk analys varit guld värd. Och detta går att applicera även på språk som eliminerar typiska C/C++-problem.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *