Verktyg för statisk kodanalys

Verktyg för statisk kodanalys Av: Peter Seimar, adi09pse 4 mars 2013 Att hitta fel, bad smells och brister i en stor kodbas kan vara både svårt och tidsödande. För att hjälpa till med det arbetet nns en rad olika kodanalysverktyg tillgängliga. En typ av dessa verktyg analyserar koden utan att köra den och kallas för statiska kodanalysverktyg. Jag vill med den här studien gå genom grunderna för hur statisk kodanalys fungerar, både som koncept och rent tekniskt. Till min hjälp har jag en samling artiklar och några av de större analysverktygen till Eclipse. Jag kommer med verktygen att inrikta mig specikt på Java, då jag kommer ha tillgång till ett ständigt växande Javaprojekt i och med att jag coachar en grupp i programvaruutvecklingskursen. Tanken är också att någon eller några i gruppen kommer få pröva på ett av verktygen om jag anser att det kan hjälpa till med att hitta problem i koden. Detta kommer dels ge mig mer input på hur verktyget fungerar och dels kunna hjälpa gruppen att få sin kodbas renare. 1

1 Sammanfattning Analysera och buggxa programkod är ett svårt och tidsödande arbete om man inte är van vid det. Till hjälp för detta nns en rad verktyg för att göra så kallad statisk kodanalys. Jag har under det pågående PVG-projektet prövat några av dessa verktyg på min projektgrupps kodbas för att hitta något verktyg som fungerar bra. Resultatet jag fann var att det nns ett par verktyg som är dels lätta och smidiga att använda och som dessutom gör ett bra jobb. 2 Teori Här följer en den teorin jag ansett vara relevant dels för att förstå hur statuisk kodanalys funegrar, vad det är bra till samt hur det fungerar i jämförelse med dynamisk analys. 2.1 Statisk kodanalys Ett verktyg för att rensa upp fel i sin kod är statisk kodanalys, vilket innebär att koden analyseras i ren textform, d.v.s. utan att kompileras och köras. Det nns väldigt många saker man kan specialisera sin analys på, såsom testcoverage, hitta vanliga buggar, generera UML-diagram m.m. Ett statiskt analysverktyg måste ha någon form av bibliotek eller referens som mall för vad det ska leta efter när det går genom koden för att hitta felen. Denna mall måste göras av människor, vilket innebär att den inte kan bli helt perfekt. 2.2 Problematik med kodanalys Ett av de stora problemen med programmering och att förutse buggar i ett program är att det är väldigt svårt att detektera dessa om man inte har stött på dem under exekvering. En bra liknelse är att låta en blind man laga hål i en vägg av okänd längd, man måste testa sig fram tills man hittar hålet/buggen, laga den och sedan leta efter nya. Det stora problemet är att det inte går att se hela bredden av programmet och på så sätt kunna förutspå buggarna. Vad man däremot kan göra är att använda sig av en uppsättning av regler och metoder för att hitta fel som brukar vara vanliga att de förekommer, såsom duplicerad kod, missade nullkontroller m.m. Den mänskliga faktorn gör att det nns en hel del fel som går att förutsäga och varna för om de dyker upp, medan det samtidigt innebär att det nns många fel som INTE går att förutsäga. Inte ens ett program med fördenerade sökregler klarar av att hitta alla fel och brister, så det kan vara värt att köra era olika verktyg för att täcka in så mycket som möjligt[10]. Ett annat problem som kan uppstå är om man har en kompilator som yttar om delar av koden p.g.a optimering exempelvis. I Java är det inget problem, då koden inte kompileras på samma sätt som t.ex. C-kod. Ett program skulle kunna gå felfritt genom en statisk analys, sedan kompileras och funka dåligt om kompilatorn gjort om för mycket. 2

Man kan göra analyser på både den faktiska koden och på bytekoden som genererats av kompilatorn. Fördelen med att köra analys på den faktiska koden är att det är lättare att detektera mönster som kan ses som felaktiga, kodkonventioner m.m. Bytekoden däremot går mycket snabbare att analysera men det går inte göra lika mycket med den. Bytekoden är dessutom väldigt svår att koppla till högnivåkoden[1]. Som tidigare nämnt är det extremt svårt, för att inte säga omöjligt, att förutspå och detektera allt som kan gå fel med ett program. Kodanalys kan hjälpa oss med de vanligaste felen men kan dessvärre omöjligt garantera 100% felfrihet. 2.3 Statisk eller dynamisk analys? När man ska analysera sin kod efter fel nns det två olika typer av analyser man kan göra, dynamisk och statisk kodanalys. För att ge en mer komplett bild av kodanalys bör den dynamiska delen också nämnas för att ge lite mer förståelse för vad den statiska analysen faktiskt gör och går ut på. Jag kommer härmed att gå genom skillnaderna mellan de båda varianterna och berätta om vad de kan användas till. För att komplettera statisk analys av kod kan man göra en dynamisk analys, vilket innebär att verktyget kör koden direkt på processorn eller hellre i en virtuell processor. Fördelen med att köra en dynamisk analys är att man kan se hur programmet beter sig nere på ren instruktionsnivå i processorn. Detta kan göra det lättare att optimera programmet för att bättre klara av pipeliningen i processorer. Dynamisk analys ger möjlighet att testa programmet i skarpt läge med många olika inparametrar, till skillnad från den statiska som lämpar sig bättre för att hitta bad smells, vanliga buggar samt brott mot kodkonventioner. Code coverage kan teoretisk sett beräknas med båda varianterna men lämpar sig bäst när man gör det dynamiskt då man kan se vilka rader kod som faktiskt körs, medan den statiska varianten får problem vid if-satser och andra vägval i programmet. Minnesläckage är ett bra exempel på ett allvarligt problem som kan detekteras både med statisk och dynamisk analys. Den statiska metoden går ut på att kontollera de olika allokering- och deallokeringsfunktionerna i ett program för att försöka se om det är något minne som inte lämnas tillbaks. Java har inte det problemet men programmerar man i exempelvis C är det väldigt viktigt. Man kan då använda exempelvis Memcheck/Valgrind[4] (används bl.a. i kursen Algoritmimplementering, EDAF15[7] på lth) Den dynamiska varianten är dock bättre på att detektera minnesläckagen eftersom att den metoden kräver att programmet faktiskt krös och gås genom, medan den statiska metoden lättare kan göra missar. Detta på grund av att det är svårt att förutse alla vägar ett program tar. Den dynamiska metoden har dock nackdelen att den bara tar en väg genom programmet(per test) vilket kan bli extremt tidsödande om det nns många vägar genom programmet. 3

Det nns vissa verktyg som använder en kombination av dynamisk och statisk analys för att detektera problem. Här följer ett citat jag ansåg beskriva hur man på ett bra genomför en analys med en blandning av statisk och dynamisk analys. Citat: This system automatically generates from a query a pair of complementary checkers: a static checker that nds all potential matches in an application and a dynamic checker that traps all matches precisely as they occur.[6] För att sammanfatta det hela bör man som programmerare använda en sund blandning av statisk och dynamisk kodanalys. De båda varianterna står inte i konkurrans med varandra, utan kompletterar snarare varandra. 2.4 Säkerhet En viktig aspekt när man programmerar större produkter som ska säljas till användare är att tänka på programmets säkerhet. Det är inget som spelar så stor roll om du programmerar en miniräknare som hobbyprojekt men när det nns kritisk information och pengar inblandade måste man kunna sätta krav på att det inte nns säkerhetsluckor i programmet. Statisk kodanalys kan hjälpa till att hitta kända säkerhetsluckor och vanliga misstag som kan äventyra programmets säkerhet och det är väldigt viktigt att informationen om dessa luckor läggs till i uppdaterade versioner av analysverktygen. Risken kan nämligen vara stor att en programmerare förlitar sig för mycket på sina analysverktyg och tror att det är lugnt när deras kod går genom felfritt. I dessa fall är det extra viktigt att poängtera att kodanalys aldrig kan vara helt att lita på, och kanske inte alltid har informationen om de senaste säkerhetsluckorna. Säkerhetsluckorna är inte heller alltid beroende av en enda faktor, vilket kan göra det ännu svårare för verktygen att hitta dem. Det kan vara en kombination av dålig design, implementation, utförande eller kravspecikation[2]. 3 Verktyg Följande är en genomgång av de analysverktygen jag prövat och ansett att de är vettiga att nämna. Urvalet av verktyg är gjort med fokus på vad som faktiskt används av programmerare genom att kolla runt mest på forum som t.ex. StackOverow [7]. 3.1 FindBugs Det här verktyget var ett av de första jag prövade och var väldigt simpelt att använda. Vid en första genomsökning av teamets kod hittade den 7 problem såsom missade nullkontroller, samt varning för att använda en vanlig likhetskontroll(==) för att jämföra strängar och hänvisade till String.equals()-funktionen istället. Det går dessutom att ändra känsligheten på FindBugs, vilket medför att det går 4

att få den riktigt pedantisk och markera fel i kodkonventioner m.m. Verktyget är lätt att använda, och gör genomsökningen direkt via en knapp i Packageexplorer-fältet. Det går att göra sökningar på enstaka klasser, hela paket eller på hela projektet. 3.2 PMD Jag är lite osäker på om jag verkligen ck PMD att fungera när jag prövade det, då det inte detekterade ett enda fel i koden. Det är möjligt att kodbasen var för liten, att pluginet var felkongurerat eller för okänsligt, eller så var det helt enkelt inget fel med koden. Ett par av gruppmedlemmarna prövade att använda PMD i ett senare stadie i projektet för att detektera bad smells i kodbasen och ck det att fungera ypperligt. Verktyget genererade i genomsnitt 1.6 anmärkningar per rad kod, vilket resulterade i extremt många anmärkningar. PMD delar in anmärkningarna i fem kategorier beroende på hur kritiska de är. De esta anmärkningarna var på väldigt låg prioritet, så verktyget var ganska pedantiskt, på ett bra sätt. Gruppen har inte använt verktyget systematiskt under projektet, utan bara vid ett par enstaka tillfällen men har själva sagt att det var väldigt smidigt och lätt att använda och skulle varit praktiskt att ha använt verktyget mer systematiskt och främst vid refaktoriseringsarbetet. De tyckte främst att det var bra att se olika kodkonventioner de bröt mot och även bad smells. Dock var inte pluginet helt perfekt och pekade era gånger ut olika xar som motsade varandra eller som i sig skulle skapa nya klagomål. 3.3 jdeodorant jdeodorant är ett populärt verktyg för att specikt detektera bad smells i koden. De bad smells det kan upptäcka är långa metoder, klasser som använder andra klassers metoder för mycket(feature envy), gudklasser och föreslår vart man kan införa strategy- och template methodmönstrena. Verktyget är ganska simpelt att använda och gör ett helt okej jobb. Dock gör dess inriktning att det inte är användbart till så mycket annat. Jag fann inte jdeodorant jätteintressant, främst för att jag tycker det är mer direkt hjälpsamt om man kan hitta buggar och säkerhetsrisker. Bad smells är givetvis viktigt att hitta också men jag tycker inte det är nödvändigt att använda ett plugin för att hitta långa klasser och metoder och ställen där jag kan göra subklasser och strategymönster. Feature envy är väl egentligen det jag anser svårast att se direkt i koden, och det är väl egentligen där jag skulle använda jdeodorant. I större projekt på era tusen rader kod däremot skulle ett sånt här program vara mer användbart, då det skulle vara extremt tidsödande att själv hitta dessa bad smells. Det verkar inte nnas allt för många (väl fungerande) bad smelldetekteringsverktyg till Java tyvärr, men jdeodorant verkar lovande även om de inte ger så många resultat som t.ex. PMD. Dock var i princip alla förslagen jdeodorant gav 5

vettiga, medan PMD ger en del vettiga förslag och jättemånga rent pedantiska förslag på förbättringar. 3.4 CodePro CodePro är ett väldigt stort verktyg med många funktioner som andra enskilda verktyg har var för sig, och är väldigt lätt och smidigt att använda, vilket gjorde att jag valde det som min personliga favorit och har mest fördjupat mig i hur man använder det. Funktionen. Verktyget har ett antal funktioner som blandar både statisk och dynamisk analys för att täcka in en stor rad av metrics och fel. Den första funktionen kallas Audit och gör en sökning efter ett 20-tal olika säkerhetsrisker[3] i koden såsom hårdkodade lösenord, känsliga resurser som ligger allt för tillgängliga m.m. Det nns inbyggda funktioner för att skapa testfall och factorymetoder men de ck Eclipse att krascha, så jag har inte kunnat se hur bra de gör sitt jobb. CodePro kan dessutom generera väldigt mycket metrics om koden, dels som ren statistik men även relationsgrafer mellan klasser och metoder. Dessa diagram blir dessvärre väldigt röriga då de tar med en del klasser och metoder i de interna Java-biblioteken, vilket ger en relationsgraf med nästan 100 noder i vårt projekt. Test-coverage går även att göra men detta räknas inte till den statiska kodanalysen, så det har jag inte riktigt testat. Jag har dock förståt att det skulle kunna ersätta coverage-verktyget EclEmma. Slutligen går det även att detektera död och duplicerad kod som visas i ett väldigt lättförståeligt interface. Som tidigare nämnt tycker jag att CodePro var det bästa av de verktyg jag testat. Även om det säkert nns många nischade verktyg som var och sig är bättre på den enskilda uppgift de är utformade så är det väldigt praktiskt att ha så mycket funktionalitet samlat på ett och samma ställe. Nackdelen med CodePro dock är att nästan ingen bad smell detekteras, vilket ändå kan vara väldigt viktigt att hitta, speciellt i större och mer komplexa kodbaser. Det jag saknade mest med CodePro var dock att det inte detekterades abd smells i koden. Detta kunde givetvis lösas genom att köra PMD eller jdeodorant utöver CodePro. En av studenterna i projektgruppen prövade på CodePro vid ett par tillfällen och tyckte att det var bra att det fanns så mycket funktionalitet samlad, men att varje funktionalitet i sig inte var så djupgående och bra. Exempelvis funktionen för att generera UML-diagram ansåg studenten vara väldigt dålig i jämförelse med t.ex. Green UML [9] (jag prövade inte Green i den här studien) då CodePros diagram var väldigt rörigt. 3.5 Sammanfattning Efter att ha prövat olika verktyg så är det lite svårt att bestämma vilket som är värt att satsa på. Jag valde CodePro som favorit för jag tyckte att den hade många funktioner samlade och det var mycket smidigare att ha ett enda plugin 6

i Eclipse som sköter analysen, istället för att ha 6-7 olika som var och en är bra på sin sak. I mitt fall stötte jag på problem när jag hade många plugins, vilket dock enbart var problematiskt på grund av hårdvaru- och minnesbrist. Hade jag gjort samma studie med mer än en vanlig skoldator och det begränsade utrymmet eleverna har på datorerna hade jag kanske föredragit att ha de olika nischade verktygen istället. Jag antar att det är en smaksak egentligen. Märker jag att CodePro gör en av funktionerna för dåligt kan man installera ett av de andra pluginen för att få just den funktionen gjord bättre. Kort och gott beror det helt på hur djupgående och specik analys man är tue efter att genomföra. Bild: Gränssnittet för jämförelse av liknande kod [5]. 4 Slutsats Jakten efter felfri kod är väldigt svår, men det nns många metoder och verktyg för att göra en del av arbetet åt dig. Jag har bara testat ett fåtal av de som verkade vettigast för Java och anser personligen att CodePro är det vettigaste, då det har samma funktionalitet some ett antal olika verktyg kombinerat i ett enda verktyg. Det stora problemet med CodePro dock är att det inte täcker in särskillt mycket när det kommer till bad smells. Det är svårt att lyckas med allt när man gör ett sådant plugin och olika plugin med samma syfte kan hitta en hel del olika buggar och kompletterar på så sätt varandra. Man får i slutändan göra en övervägning om hur många plugins man vill installera och köra. Fler plugins ger större täckning för buggar, bad smells m.m. men innebär att man får ett Eclipse som är rörigare och att man får lägga ner mer tid på att utföra analyserna. 7

Jag hade själv problem med att Eclipse blev lite för fullt och långsamt av att ha så många testverktyg jag hade när jag hade som mest(några dåliga tog jag aldrig upp i den här rapporten, då jag aldrig ck dem att fungera), vilket resulterade i väldiga problem med skoldatorerna. CodePro enbart kunde ersätta de esta av dem utan att förstöra Eclipse. Jag fann under arbetet att även dynamisk programanalys verkade väldigt intressant och jag hade gärna skrivit om det om inte projektet hade varit i Java. Jag har lite erfarenhet av sådana verktyg för C och tycker det är ganska intressant när det kommer till minneshantering och pipelining i processorer m.m. Dock hade det inte varit lika intressant i Java då man kör på en virtuell maskin och minnesdeallokeringen sköts av sig själv. Referenser [1] Panagiotis Louridas, Static Code Analysis. IEEE 2006. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1657940 [2] Alexandru G. Bardas Static Code Analysis. Romanian Economic and Business Review 2011 http://www.rebe.rau.ro/repec/rau/jisomg/wi10/jisom-wi10-a10.pdf [3] CodePro Audit Rule Set CodePro Analytics, Eclipse, 27-03-2012 https://developers.google.com/java-dev-tools/codepro/doc/features/audit/security [4] Julian Seward Nicholas Nethercote Using Valgrind to detect undened value errors with bit-precision http://static.usenix.org/event/usenix05/tech/general/full_papers/seward/seward_html/ [5] Pawel Michalski http://pawel-michalski-javnie.blogspot.se/2012/10/codepro-analytix-by-google.html [6] Michael Martin, Benjamin Livshits, Monica S. Lam Finding Application Errors and Security Flaws Using PQL: a Program Query Language 8

http://people.cs.umass.edu/~emery/classes/plas/pql.pdf [7] Stack Overow http://stackoverflow.com/ [8] Algoritmimplementering, EDAF15 http://cs.lth.se/edaf15 [9] Green UML plugin for Eclipse http://green.sourceforge.net/ [10] Nick Rutar, Jerey S. Foster A Comparison of Bug Finding Tools for Java http://www.cs.umd.edu/~jfoster/papers/issre04.pdf 9