Så skriver du bättre kod med verktyg för linting, formatering och analys

Kodgranskningar är utmärkta för att upptäcka bristfällig design och dela kunskap på en övergripande nivå, men buggar kan ibland gå obemärkta förbi. I det här blogginlägget visar vi hur du kan kombinera linting-, formaterings- och analysverktyg för att upptäcka problem i koden som kanske inte fångas upp i en granskning. 

Programmeringsspråk och designmönster utvecklas ständigt, så även dessa verktyg och deras konfigurationer behöver underhållas aktivt för bästa möjliga funktionalitet, läsbarhet och aktuell syntax. Utvecklare bör inte heller vara rädda för att refaktorera kod vid uppdateringar och korrigeringar, även när koden redan fungerar som den ska, om de upptäcker ett bättre sätt att uppnå resultatet. Men om linting-, formaterings- och analysverktyg används väl redan från början av utvecklingen, behöver betydligt mindre refaktorering göras i förvaltningsfasen. Det kan i slutändan spara mycket tid och värdefulla resurser för alla inblandade.

Vi går igenom tre olika typer av användbara verktyg för din kod, vad du kan uppnå med dem och hur du kommer igång med dem direkt i utvecklingen. Men först definierar vi vad bra, underhållbar kod innebär i det här blogginlägget.

1. Bra kod gör det den ska

Först och främst måste koden fungera. Allt annat är i stort sett värdelöst om koden innehåller buggar. Verktygen bör därför hjälpa till att eliminera potentiella buggar.

1. Bra kod är lätt att läsa och ändra

Om koden är svår för människor att förstå går läsningen smärtsamt långsamt, och ändringar leder sannolikt till buggar. Verktygen bör därför öka enkelheten och tydligheten. 

1. Bra kod följer beprövad praxis

Det finns vanligtvis många sätt att implementera en viss logik, och vissa av dem verkar lika bra. Men vi bör göra medvetna val för att skapa konsekvens, inte bara inom en och samma kodbas utan även mellan olika projekt. Igenkänning ökar trots allt läsbarheten. Verktygen bör därför öka konsekvensen och varna för dålig praxis.

Verktygen för bättre kod

• Linters

Linters

• Linters som ESLint och Pylint används främst för att upptäcka logiska problem i koden. De är särskilt viktiga för tolkade och löst typade språk som JavaScript och Python, eftersom de saknar ett extra kompileringssteg som fångar upp fel. JavaScript är i synnerhet ett mycket dynamiskt och egenartat språk som kan leda till märkliga, oavsiktliga beteenden om beprövad praxis inte följs. Du bör till exempel använda === och !== i stället för == och !=, eftersom JavaScripts typkonvertering minst sagt är väldigt ologisk. Som tur är finns det en ESLint-regel för detta och andra liknande, vanliga metoder. 

• ESLint är också mycket utbyggbart och kan användas och konfigureras för att varna för nästan allt. För att utöka standardregeluppsättningen bör du troligen använda plugins för alla specifika ramverk, kanske även för vissa bibliotek och för tillgänglighet (till exempel eslint-plugin-jsx-a11y). Eftersom varje projekt är unikt bör reglerna konfigureras utifrån projektets versionshantering. Ju närmare konfigurationerna ligger de rekommenderade standardinställningarna, desto enklare är de dock att underhålla och följa enligt beprövad praxis. En bra utgångspunkt är att använda den senaste versionen av alla paket och de rekommenderade regeluppsättningarna för var och en av dem (se exempelkonfigurationen). Om en regel inte passar projektet kan den enkelt inaktiveras genom att sättas till ”off”.

• Linters är mest användbara när de integreras i editorn och skannar koden medan du skriver, så att du får återkoppling så snabbt som möjligt. Möjliga fel markeras då alltid och kan åtgärdas snabbt. Anta till exempel att jag arbetar med en React-app och implementerar ett nytt formulär. Utan ESLint och eslint-plugin-jsx-a11y är det troligt att formuläret blir svårt att navigera med tangentbord eller omöjligt att förstå fullt ut med skärmläsare, utan att någon märker det förrän det har orsakat verkliga problem. Men med en välkonfigurerad linter och editor får jag omedelbara varningar om ett interaktivt element saknar tangentbordshändelser eller om bilder inte har icke-redundanta alt-attribut. 

• Linters kan även användas som stilguider för formatering, som i populära eslint-config-airbnb, men enligt min mening är det bättre att säkerställa en bra stil med automatiska formaterare och låta lintern fokusera enbart på logiska problem.

• Formaterare

• Formaterare som Prettier och Black används för att säkerställa en konsekvent stil i projektet genom att formatera koden enligt sin regeluppsättning. Formaterare används som ett komplement till linters: Linters används för kodkvalitet, formaterare för formateringsregler. Förutom JavaScript och TypeScript kan Prettier även formatera bland annat CSS, Less, SCSS, HTML, JSON, Markdown och YAML. Eftersom kodens formatering egentligen inte påverkar hur koden fungerar är det inte så viktigt vilka regler som används, utan att det finns någon gemensam regeluppsättning. Därför är de bästa formaterarna tydliga i sina ställningstaganden och kräver ingen konfiguration alls. De flesta formateringsregler kan diskuteras, men standardinställningarna är optimerade för läsbarhet och det finns sällan något logiskt skäl att avvika från dem. För att arbeta så effektivt som möjligt är det troligen bäst att ha ett formateringssteg i en pre-commit-hook, så att det blir omöjligt att committa felaktigt formaterad kod. Då kan utvecklaren skriva koden i det format som känns mest bekvämt. Dessutom kan formaterare integreras med editorn för att formatera koden när filen sparas. Fördelarna är enorma: mycket tid sparas när du inte längre behöver fatta beslut om stil eller manuellt skriva mellanslag och andra valfria tecken. Stora kodbaser kan formateras på några sekunder. Formaterare gör det också väldigt enkelt att börja bidra till en kodbas, eftersom du inte längre behöver lära dig projektets formateringskonventioner.

• Statisk kodanalys

• Statiska kodanalysverktyg, som SonarQube, analyserar och tillhandahåller mätvärden för din kodbas. SonarQube har bra stöd för 27 olika språk, inklusive CSS och HTML. Det är särskilt bra på att hitta svårupptäckta buggar som andra verktyg eller människor kan missa, genom att utforska alla möjliga exekveringsvägar. Det varnar för kodlukt som gör koden svårare att underhålla, även om den fungerar som avsett, till exempel duplicerad kod, alltför komplex kod och kod utan testtäckning. Det varnar också för sårbarheter och potentiellt osäker kod samt mäter tillförlitlighet, säkerhet, underhållbarhet, testtäckning och dupliceringar i hela kodbasen och i ny kod som tillkommer. SonarQube används bäst som en del av CI/CD-pipelinen för att skanna koden varje gång nya ändringar pushas till en övervakad branch. Som bonus finns även tillägget SonarLint för kodredigerare, som kan användas tillsammans med SonarQube för att varna för fel medan du skriver kod. 

Slutsatser

Alla verktyg som nämns här är snabba och enkla att börja använda. De stöder och följer beprövade metoder och ger mycket värde genom att minska tiden och kostnaderna för att skriva bra kod. Den mest effektiva kombinationen är att: linta medan du skriver, formatera i en pre-commit hook och köra SonarQube i CI/CD-pipelinen. De fungerar som automatiska kodgranskningar av ändringar, vilket ofta räcker för uppgifter inom mjukvaruförvaltning. Alla kan införas när som helst under mjukvarans livscykel, men det är bättre, effektivare och enklare att börja använda dem från början. Tillsammans med bra teknikval, design och regelbundna uppdateringar bidrar de till att kodbasen förblir så lätt att underhålla som möjligt, både nu och i framtiden.