Djupstudie Verktyg för att förebygga problem i källkod Anders Forslund (d04afr@student.lth.se) Anders Lund (et05al1@student.lth.se) 2 mars 2010
Sammanfattning Då kodningsstandard ej hålls så blir ofta kod svår att förstå och arbeta med. Detta resulterar i vad som kallas illaluktande kod och den här studien tar upp olika av de största mjukvaruverktyg för att nna illaluktande kod i Java-program. Olika typer av vanligaste sorters dålig kod tas upp och verktygen testas på projekt som innehåller åtskilliga sorters illaluktande kod. Resultaten visar på att verktygen är goda hjälpmedel för att nna dålig kod, men de nner bara vissa typer av illaluktande kod och missar ofta väldigt viktiga saker. Dessa brister tas upp i studien och jämförs mot varandra. Verktygen kan i dagsläget endast användas som ett komplement till manuellt arbete. Olika sätt att göra koden mer lättläst och lättarbetad presenteras kort här. 2
INNEHÅLL INNEHÅLL Innehåll 1 Inledning 4 2 Code Smells 4 2.1 Kommentarer............................. 5 2.2 Långa metoder............................ 5 2.3 Långa parameter-listor........................ 5 2.4 Duplicerad kod............................ 5 2.5 Stora klasser............................. 5 2.6 Inkonsistenta/dåligt namngivna metoder.............. 6 2.7 Död kod................................ 6 2.8 Oanvända variabler/objekt..................... 6 3 Refaktoriseringar 6 4 Testade verktyg 7 4.1 Metodik................................ 7 4.2 Resultat................................ 8 4.2.1 Eclipse............................. 8 4.2.2 PMD............................. 9 4.2.3 Checkstyle.......................... 10 4.2.4 FindBugs........................... 10 4.3 Analys................................. 11 5 Otestade verktyg 11 5.1 Japroch................................ 12 5.2 Elbereth................................ 12 6 Slutsats 12 3
2 CODE SMELLS 1 Inledning Då era personer arbetar med kod så nns alltid risken att kodning inte sker enhetligt. Om någon kodar enligt ett visst mönster och någon annan vill refaktorisera detta, som i sin tur kodar på ett annat sätt, uppstår ofta problem [1]. Det nns många er typer av fel, så kallade kodlukter, och det går inte att formulera ett generellt sätt att lösa dessa om det inte formuleras extremt abstrakt. Ofta är det svårt att hitta dessa fel. De upptäcks ofta av duktiga programmerare som nner det intuitivt fel. För att underlätta för utvecklare så har det släppts verktyg som är till för att nna dessa felaktigheter i programkod. För Java nns det åtskilliga. Genom att studera vetenskapliga dokument och testa olika verktyg kan man nna i vilken grad dessa kan appliceras på PVGprojektet. Några välkända verktyg för att hitta code smells i Java kommer att testas och analyseras lite senare i denna rapport. 2 Code Smells Illaluktande kod är något som alla programmerare någon gång kommer stöta på under sin karriär. Skickliga utvecklare med stor kunskap brukar dock ha en känsla för design av kod så att lukter kan minskas markant. Även olika verktyg kan användas för att identiera dessa och också åtgärda dem. Vad är då illaluktande kod? Det är ett begrepp som myntades av Kent Beck i WikiWikiWeb, världens första wiki. Han denierade det som en liten ledtråd till att något i koden hade gått fel, att det fanns ett djupare problem. Det kan vara allt från att programmet i fråga är långsammare än vad det behöver vara till att programmet är svårt att vidareutveckla för andra programmerare. Metaforen code smell blev dock vanligare i folkmun efter att ha använts i boken Refactoring: Improving the Design of Existing Code skriven av M. Fowler [2]. Nedan kommer några av de vanligaste kodlukterna listas och förklaras [3]. Notera att kodlukter kan skilja sig åt i olika programpråk (här kommer det mest fokuseras på Java) och att vissa är mer eller mindre allvarliga samt att de i allas ögon inte alls anses vara fel. Kommentarer. Långa metoder. Långa parameter-listor. Duplicerad kod. Stora klasser. Inkonsistenta/dåligt namngivna metoder. Död kod. Oanvända variabler/objekt. 4
2.1 Kommentarer 2 CODE SMELLS 2.1 Kommentarer En metods namn bör vara skriven så att man förstår vad dess uppgift är. Ett bra exempel är getinvoicablecreditlimit() istället för getinvcrlmt(). Därför ska en metodkommentar inte beskriva vad metoden gör, utan snarare varför metoden nns. I vissa fall, till exempel kod skriven i Assembler som är väldigt svår att förstå, måste däremot kommentarer beskriva vad koden gör. 2.2 Långa metoder En lång metod gör att det blir svårare att se vad metoden i fråga egentligen gör, den blir oöversiktlig. Men vad är egentligen en lång metod? Hur många rader kod är långt? Ett ganska vanlig generellt svar på denna fråga är att det nns ingen tydlig denition, utan man bör helt enkelt se till att en metod har en enda huvuduppgift. Gör den för mycket bör den refaktoriseras, förslagsvis genom att delas upp i era mindre metoder. 2.3 Långa parameter-listor Alan Perlis, en pionjär inom programvaruutveckling sade en gång If you have a procedure with 10 parameters, you probably missed some. Den underliggande meningen är att en metod ska ha så få parametrar som möjligt. Istället för att skicka in parametrar från ett visst objekt är det ofta bättre att skicka in hela objektet. En metod med många parametrar är svårläst och svår att tolka. Istället för: int low = daystemprange().getlow(); int high = daystemprange().gethigh(); withinplan = plan.withinrange(low, high); gör man exempelvis: withinplan = plan.withinrange(daystemprange()); 2.4 Duplicerad kod Redundans i kod är något man helst vill undvika. Ofta uppkommer det på grund av en dålig eller lat programmerare (i form av copy-paste). En anledning till att undvika duplicerad kod är exempelvis att den blir svårare att förstå för en annan utvecklare. En lång metod med duplicerad kod är svårare att snabbt komma in i än en kort refaktoriserad. Det blir också svårare att uppdatera koden eftersom man måste ändra på era ställen. Lösningen på problemet är att extrahera den redundanta koden och skapa EN metod av det istället som sedan kan anropas från era ställen. 2.5 Stora klasser Likt långa metoder är även långa/stora klasser en riktig stinkbomb. En stor klass kan ofta identieras genom att studera antalet attribut. Är det många sådana är det i många fall även en för stor klass som gör för mycket och som borde delas upp. 5
2.6 Inkonsistenta/dåligt namngivna metoder 3 REFAKTORISERINGAR I guren nedan visas ett exempel. Figur 1: Stor klass refaktoriseras 2.6 Inkonsistenta/dåligt namngivna metoder När det gäller metoder (även variabler, klasser etc.) bör de vara namngivna så att man förstår vad dess uppgift är. Det ska vara tydligt utan att behöva läsa kommentarer. En konsistent namngivning är också den viktig för att inte skapa förvirring. Att följa Code Conventions for Java av Sun gör att detta inte bör blir några problem. När man döper metoder bör man också undvika redundans. Det är att föredra schedule.add(course) framför schedule.addcourse(course). 2.7 Död kod En variabel, metod, parameter eller annan typ av kodfragment som aldrig exekveras. Som utvecklare eftersträvar man alltid ren kod som är lätt att förstå och död kod ingår inte i denna kategori. 2.8 Oanvända variabler/objekt Till skillnad från död kod så kan oanvända datatyper exekveras och ta upp plats i minnet. Men likt död kod vill man undvika detta. 3 Refaktoriseringar När verktyg har funnit illaluktande kod så är det en lämplig ide att modiera koden. Det nns ett väldigt begränsat stöd för att göra det helt automatiskt. Det nns refaktoriseringsverktyg, men inget som direkt ansluter processen att automatiskt nna illaluktande kod med refaktorisering. Detta får göras manuellt. För den sortens illaluktande kod som vi behandlat i testning nns följande refaktoriseringlösningar: Långa metoder : Löses i första hand genom att extrahera koden till en egen metod. Duplicerad kod: Löses genom att extrahera koden till en egen metod. Ibland är det så att den duplicerade koden har små variationer på de ställen där den förekommer. Då får lite mer komplext arbete ske när koden extraheras, men det är helt genomförbart. 6
4 TESTADE VERKTYG Död kod: Om koden avsiktligt placerats som död så bör den tas bort från projektet. Nästlade if-satser : Försök sätta de booleska uttrycken som en if-sats istället för era. 4 Testade verktyg Manuell jakt på illaluktande kod är något som är extremt tidskrävande och kan vara väldigt svårt. Nedan nns verktyg som ska underlätta detta genom att automatiserat leta upp illaluktande kod. Alla testade verktyg är open source och använder sig av statisk analys, vilket innebär att källkoden analyseras. Detta gör att programmet inte behöver exekveras. FindBugs skiljer sig något genom att analysera bytekod statiskt, det vill säga kompilerade klassler. PMD är ett öppet verktyg som söker efter code smells i Java-kod. Verktyget kan användas som plugin till ett tiotal utvecklingsmiljöer. PMD analyserar kod utan att exekvera den vilket gör att den kan kommentera detaljer som variabelnamn [4]. FindBugs letar huvudsakligen efter buggar, men ger även varningar då väldigt avancerade funktioner i ett språk används. På grund av dess sätt att analysera ett program så kan inte FindBugs kommentera saker som variabelnamn [5]. Eclipse är en utvecklingsmiljö som ger varningar för åtskilliga saker som relaterar till illaluktande kod. Eclipse analyserar koden utan att den behöver exekveras och kommenterar saker som den anser vara direkta felaktigheter [6]. Checkstyle är ett verktyg som främst är till för att se till att kodningsstandarder följs. Indirekt innebär det att illaluktande kod hittas då de ofta uppstår när kodningsstandarder bryts [7]. 4.1 Metodik Verktygen har testats på två sätt. För en realistiskt testning har tre projekt som behandlar samma uppgift använts. Detta är projekt som utvecklas under sju heldagar av tio utvecklare som går kursen EDA260 på Lunds Tekniska Högskola (kursen förkortad PVG). Projekten innehåller illaluktande kod som uppstått på naturligt sätt. Då utvecklarna kan tänkas vara för duktiga för skriva kod som luktar väldigt illa så har det skapats ett, av författarna, egenskrivet projekt. Det består av medvetet illaluktande kod. Kodlukterna har denierats och implementerats enligt följande: Korta metodnamn. Testas genom att ha med en metod vars namn är två tecken. Långa metodnamn. Testas genom att ha med en metod vars namn är tjugo tecken. Långa metoder. Testas genom att ha med en metod på över 100 rader kod. 7
4.2 Resultat 4 TESTADE VERKTYG Duplicerad kod. Testas genom att dels ha återkommande kodstycken, men också genom att ha snarlik kod på era ställen. Död kod. Testas genom att ha kod i en if-sats där det boolska uttrycket alltid är falskt. Koden kommer aldrig att exekveras. Många parametrar. Testas genom att ha en metod som har tio parametrar. Nästlade If-satser. Testas genom att ha fyra if-satser i varandra. Åtskilliga verktyg körs på projekten och de kodlukter som identieras, som relaterar till de faktiska vi skrivit, registreras. Då det nns olika standarder att identiera illaluktande kod så hittar vissa verktyg väldigt många saker som enligt andra verktyg ej är illaluktande kod. Dessa nämns men studeras ej i detalj. 4.2 Resultat 4.2.1 Eclipse Kommentarer. Till föga förvåning varnar Eclipse ej för brist på kommentarer. Nästlade If-satser. Eclipse hittar ej nästlade if-statser. Långa metoder. Eclipse varnar ej för långa metoder. Långa parameter-listor. Eclipse varnar ej för långa parameter-listor. Duplicerad kod. Eclipse varnar ej för duplicerad kod. Stora klasser. Eclipse varnar ej för stora klasser. Inkonsistenta/dåligt namngivna metoder. Eclipse varnar för dålig namngivning på paket och klasser. Varning uppstår endast när versaler och gemener används fel. Död kod. Eclipse hittar endast vår döda kod om det booleska uttrycket som gör if-satsen död, ligger i samma klass som if-satsen. Om if-satsen anropar en konstant från ett annat objekt så kommer det inte någon varning. Oanvända variabler. Oanvända variabler varnar programmet om direkt. Skapas ett objekt utan att användas på något sätt ges en varning. Gör man ett nonsens-anrop på objektet försvinner varningen, även om metodanropet inte fyller någon funktion. Se kodexempel nedan: String text="12345"; //varning för oanvänt objekt syns text.charat(2); //ingen varning syns om denna metod anropats Eclipse varnar inte för allt som man vill att ett code smell detection tool ska varna för, men hittar ändå ganska mycket. För att vara en integrerad utvecklingsmiljö (IDE) gör Eclipse väldigt mycket. 8
4.2 Resultat 4 TESTADE VERKTYG Figur 2: Eclipse detekterar död kod. 4.2.2 PMD Kommentarer. PMD ger inga varningar för dåliga kommentarer. Nästlade If-satser. Verktyget nner nästlade if-satser och rekommenderar lösningsförslag. Långa metoder. PMD hittar långa metoder. Vår långa metod får varning med meddelandet Avoid really long methods. Långa parameter-listor. PMD hittar metoden med tio parametrar och varnar för att det är för många. Duplicerad kod. Verktyget låter användaren specicera hur stort ett kodstycke ska vara för att den ska hitta duplicerad kod. PMD är väldigt bra på att hitta duplicerad kod och hittar den även om det används olika variabelnamn på de olika platserna. Både i riktiga projekt och i dummy-projektet nner PMD duplicerad kod. Stora klasser. PMD ger varning då klasser är för stora. Inkonsistenta/dåligt namngivna metoder. PMD varnar för namn som är för korta och för långa. Används versaler på fel sätt genereras även en varning. Död kod. PMD nner död kod, men på samma sätt som Eclipse hittas inte död kod om inte det booleska uttrycket i if-satsen ligger i samma klass. Oanvända variabler. PMD varnar för objekt som inte används. PMD hittar väldigt mycket, men mycket relaterar till annat än vad i denna studien denierats som illaluktande kod. Exempelvis vill PMD att objekt som skickas in i en metod utan att förändras ska sättas som final när metodparametrarna skrivs. Detta är standard enligt C++ kodningskonventioner men är inte något som är ett måste i Java. PMD upplevs som ett väldigt kompetent verktyg men många av dess varningar måste ltreras bort. Då det används som en plug-in i Eclipse är det något svårt att sortera resultaten, då användaren får en lista med alla varningar, vilket i våra fall är era tusen. Det blir väldigt tidskonsumerande att studera denna resultatsrepresentation. 9
4.2 Resultat 4 TESTADE VERKTYG Figur 3: Exempel på PMD:s gränssnitt. 4.2.3 Checkstyle Kommentarer. Checkstyle klagar på brist samt felaktigt skriven Javadoc, vilket är en väldigt bra egenskap. Nästlade If-satser. Verktyget noterar ej nästlade if-satser. Långa metoder. Checkstyle nner ej långa metoder. Långa parameter-listor. Checkstyle klagar då det nns mer än 7 parametrar i en metod. Duplicerad kod. Checkstyle nner ej duplicerad kod. Stora klasser. Verktyget genererar varning då en metod är på väldigt många rader. Inkonsistenta/dåligt namngivna metoder. Checkstyle ger extremt bra varningar för namngivning. Konventioner följs väldigt strikt och alla kommentarer, objekt, parametrar, metodnamn, klassnamn, konstanter etc. får varningar om de inte följer standarden helt. Död kod. Checkstyle nner ej död kod. Oanvända variabler. Checkstyle klagar ej på oanvända variabler. Checkstyle påminner om PMD. Den hittar några extra fel, men saknar några som att hitta långa metoder och nästlade if-satser. Verktyget upplevs som väldigt mycket mer relaterat till kommentarer och namngivning än PMD. Verktyget är knepigare att arbeta med i Eclipse än PMD, då det är ännu svårare än det är i PMD att sortera och ltrera olika typer av fel. 4.2.4 FindBugs Kommentarer. FindBugs klagar ej på brist på kommentarer. Nästlade If-satser. FindBugs noterar ej nästlade if-satser. Långa metoder. Verktyget nner ej långa metoder. Långa parameter-listor. FindBugs klagar ej på långa parameter-listor. Duplicerad kod. FindBugs nner ej duplicerad kod. Stora klasser. FindBugs klagar ej på stora klasser. 10
4.3 Analys 5 OTESTADE VERKTYG Död kod. Verktyget nner ej död kod. Oanvända variabler. FindBugs klagar på oanvända variabler. FindBugs hittar endast oanvända objekt. Verktyget söker mer efter väldigt specika saker som till exempel varning när MyObject.equals anropas om det råkar vara ett Comparable-objekt. De generella saker som testas här hittar inte FindBugs. Det upplevs tveksamt att kalla FindBugs ett verktyg för att identiera illaluktande kod. Verktyget har potential för att höja kodkvalitet men verkar inte kunna nna det denna studien relaterar till. 4.3 Analys Verktygen fungerar inte fullt så bra att de kan ersätta manuellt arbete. Eclipse ger information som underlättar programmerandet väldigt mycket, men som ändå är ganska lätta att hitta manuellt. FindBugs ger ännu färre meddelanden. PMD ger relativt mycket och ser något mer komplexa felaktigheter, men mycket saknas fortfarande. Testkoden testar förstås inte dessa program på alla aspekter och låter därför inte dem visa full potential. Med det sagt är det ändå udda att endast PMD ger varningar för duplicerad kod, och död kod får man endast varning för om man skrivit död kod på ett specikt sätt som passar verktygen. PMD är även väldigt inkonsekvent. På något ställe i koden nns objekt med korta namn. Dessa genererar varningar. Längre ner i koden nns andra objekt med lika korta namn, dessa genererar inga varningar. Egen testning har visat att dessa verktyg är bra komplement till manuell detektion, men räcker inte för att ersätta arbetet. Känner användare till begränsningarna i mjukvaran så kan verktygen eektivisera arbetet väldigt mycket. Användning av dessa tre verktyg på projekt är något som rekommenderas starkt. Det har exempelvis skolan Adams State College visat när de använt bland annat PMD och FindBugs i programmeringsundervisning [8]. Varje elev ck köra PMD, FindBugs och Checkstyle på sin kod och åtgärda felen som detekterades. Ibland upptäcker verktygen sådant som eleven kanske inte anser vara fel. Då kommenterades den raden med en förklaring till varför eleven i fråga inte ville ha en förändring. Enligt skolan gör detta att man lär sig tänka kritiskt och kan även ge upphov till diskussioner i klassrummet angående olika kodningsstandarder. Studenterna lär sig också att refaktorisera kod som blivit alldeles för komplex. När artikeln skrevs hade verktygen använts i undervisningen i 2 år. Under dessa år sågs en klar skillnad i kodkvalitet och läsbarhet. Skolan menar att dessa statiska kodanalys-verktyg, som nämnts ovan, skapar en medvetenhet bland studenterna om programkods kvalitet och att de lär sig på ett snabbt och enkelt sätt att upptäcka fel och brister. 5 Otestade verktyg I följande kapitel beskrivs kort olika verktyg som kan hjälpa utvecklare att spåra och åtgärda kodlukter. Av olika skäl har vi själva inte testat dem, men går ändå igenom dem lite kort. 11
5.1 Japroch 6 SLUTSATS 5.1 Japroch Att följa en bra kodstil när man programmerar är väldigt viktigt. För att hjälpa nya utvecklare har Sami Mäkelä och Ville Leppänen från University of Turku and TUCS skapat ett verktyg som visuellt kan visa var i ett program en viss stil inte följs [9]. Japroch, som verktyget heter, är fullt kongurerbart så att era olika stilar ska kunna följas. Enligt författarna nns det fyra olika aspekter av problem med kodningsstil: Typograska. Alla problem som är relaterade till det visuella utseendet i koden. Exempel på detta är indentering, placering av paranteser och maxlängd av kodrad. Syntaktiska. Problem som är relaterade till en dålig programmeringsstil även om programkonstruktionen i sig kan vara syntaktiskt korrekt. Exempelvis att man inte har en default-branch till en switch-case-sats. Semantiska. Exempelvis att klassnamn ska börja med stor bokstav och att alla deklarerade variabler borde användas i programmet. Logiska. Problem som är relaterade till den logiska strukturen i programmet. Exempel på detta är för många nästlade loopar och för många parametrar i metoder. Japroch har bra stöd för typograska och syntaktiska problem. De två andra kategorierna kan också kollas men bara i viss grad. I framtiden nns det förhoppningar att även semantiska problem ska stödjas fullt ut. 5.2 Elbereth Elbereth är ett verktyg för att spåra problem i kod och utföra refaktoriseringar [10]. Verktyget är utvecklat av studenten Walter Fred Korman från University of California. Elbereth använder sig av ett stjärndiagram-koncept för att hitta problem. Visuellt, med denna stjärndiagram-vy, kan man snabbt se klasshierarkier och komplexa klassrelationer och på sätt hitta kodlukter och dylikt. Tyvärr hittades inte programmet och kunde ej heller därför testas. 6 Slutsats De olika verktygen som testats underlättar detektering av lukter och andra brister i kod på ett bra sätt. De kan dock inte hitta alla fel och ibland fås även fel som man får analysera manuellt och besluta om åtgärd eller inte. Detta gör att programmerare lättare kan lära sig att analysera sin kod. Som Adams State College har gjort genom att införa verktyg i undervisningen, borde även det införas i de olika teamen i PVG-kursen. Ett verktyg som hela tiden påminner en om olika problem i koden gör att man snabbt blir medveten om dem och därmed också snabbt kan refaktorisera. Eftersom XP-metodiken är väldigt viktig att följa i kursen, där refaktorisering är en viktig del, är chansen stor att vissa iterationer där det krävs att man 12
6 SLUTSATS gör big bang refactorings blir mindre påtaglig om man följer en bra standard och har en hög kvalitet på koden. I slutändan kan detta ge ett bättre slutresultat med er stories gjorda, mer läsbar kod men framförallt studenter som lärt sig mycket. 13
REFERENSER REFERENSER Referenser [1] E. V. Emden and L. Moonen, Java quality assurance by detecting code smells, Los Alamitos, CA, USA, p. 97, 2002. [2] M. Fowler and K. Beck, Refactoring: Improving the design of existing code, p. 403, 1999. [3] http://wiki.java.net/bin/view/people/smellstorefactorings. [4] http://pmd.sourceforge.net. [5] http://ndbugs.sourceforge.net. [6] http://www.eclipse.org. [7] http://checkstyle.sourceforge.net. [8] S. Loveland, Using open source tools to prevent write-only code, April 2009, pp. 671 677. [9] S. Maekelae and V. Leppaenen, Japroch: A tool for checking programming style, University of Turku and TUCS, Department of Information Technology, 2004. [10] W. F. Korman, Masters thesis, elbereth: Tool support for refactoring java programs, University of California, 1998. 14