Kodmått – cyklomatisk komplexitet
När du arbetar med kodmått verkar ett av de minst förstådda objekten vara cyklomatisk komplexitet. I grund och botten, med cyklomatisk komplexitet, är högre siffror dåliga och lägre siffror är bra. Du kan använda cyklomatisk komplexitet för att få en uppfattning om hur svårt en viss kod kan vara att testa, underhålla eller felsöka samt en indikation på hur troligt det är att koden kommer att generera fel. På hög nivå fastställer vi värdet för cyklomatisk komplexitet genom att räkna antalet beslut som fattas i källkoden. I den här artikeln börjar du med ett enkelt exempel på cyklomatisk komplexitet för att snabbt förstå begreppet och tittar sedan på lite ytterligare information om faktisk användning och föreslagna gränser. Slutligen finns det ett avsnitt med citat som kan användas för att fördjupa sig i det här ämnet.
Exempel
Cyklomatisk komplexitet definieras som att mäta "mängden beslutslogik i en källkodsfunktion" NIST235. Enkelt uttryckt, ju fler beslut som måste fattas i kod, desto mer komplext är det.
Nu ska vi se hur det fungerar. Skapa ett nytt konsolprogram och beräkna omedelbart dina kodmått genom att gå till Analysera > Beräkna kodmått för lösning.
Observera att den cyklomatiska komplexiteten är 2 (det lägsta möjliga värdet). Om du lägger till icke-beslutskod ser du att komplexiteten inte ändras:
Om du lägger till ett beslut ökar värdet för cyklomatisk komplexitet med ett:
När du ändrar if-instruktionen till en switch-instruktion med fyra beslut som ska fattas går den från de ursprungliga två till sex:
Låt oss ta en titt på en (hypotetisk) större kodbas.
Observera att de flesta objekt, när du ökar detaljnivån i klassen Products_Related, har ett värde på ett men ett par av dem har en komplexitet på fem. I sig kanske denna skillnad inte är en stor sak, men med tanke på att de flesta andra medlemmar har en i samma klass bör du definitivt titta närmare på dessa två objekt och se vad som finns i dem. Du kan titta närmare genom att högerklicka på objektet och välja Gå till källkod från snabbmenyn. Ta en närmare titt på Product.set(Product):
Med tanke på alla if-satser kan du se varför den cyklomatiska komplexiteten är fem. Nu kanske du bestämmer dig för att det här resultatet är en acceptabel komplexitetsnivå, eller så kanske du omstrukturerar för att minska komplexiteten.
Det magiska numret
Precis som med många mått i den här branschen finns det ingen exakt cyklomatisk komplexitetsgräns som passar alla organisationer. Men NIST235 anger att en gräns på 10 är en bra utgångspunkt:
" Det exakta antalet att använda som en gräns är dock fortfarande något kontroversiellt. Den ursprungliga gränsen på 10 som föreslagits av McCabe har betydande stödjande bevis, men gränser så höga som 15 har också använts framgångsrikt. Gränser över 10 bör reserveras för projekt som har flera operativa fördelar jämfört med typiska projekt, till exempel erfaren personal, formell design, ett modernt programmeringsspråk, strukturerad programmering, kodgenomgångar och en omfattande testplan. Med andra ord kan en organisation välja en komplexitetsgräns som är större än 10, men bara om den är säker på att den vet vad den gör och är villig att ägna den ytterligare testinsats som krävs av mer komplexa moduler." NIST235
Cyklomatisk komplexitet och linjenummer
Att bara titta på antalet kodrader i sig är i bästa fall en mycket bred förutsägelse av kodkvalitet. Det finns en grundläggande sanning i tanken att ju fler kodrader i en funktion, desto mer sannolikt är det att det har fel. Men när du kombinerar cyklomatisk komplexitet med kodrader har du en mycket tydligare bild av risken för fel.
Som beskrivs av Software Assurance Technology Center (SATC) på NASA:
"SATC har funnit att den mest effektiva utvärderingen är en kombination av storlek och (cyklomatisk) komplexitet. Modulerna med både hög komplexitet och stor storlek tenderar att ha den lägsta tillförlitligheten. Moduler med låg storlek och hög komplexitet är också en tillförlitlighetsrisk eftersom de tenderar att vara mycket kortfattad kod, vilket är svårt att förändra eller modifiera." SATC
Kodanalys
Kodanalys innehåller en kategori av regler för underhåll. Mer information finns i Underhållsregler. När du använder äldre kodanalys innehåller regeluppsättningen för utökad designguide ett underhållbarhetsområde:
Inom underhållsområdet finns en regel för komplexitet:
Den här regeln utfärdar en varning när den cyklomatiska komplexiteten når 25, så att den kan hjälpa dig att undvika överdriven komplexitet. Mer information om regeln finns i CA1502
Att få ihop allt
Slutsatsen är att ett högt komplexitetsnummer innebär större sannolikhet för fel med ökad tid att underhålla och felsöka. Ta en närmare titt på alla funktioner som har hög komplexitet och bestäm om de ska omstruktureras för att göra dem mindre komplexa.
Citat
MCCABE5
McCabe, T. och A. Watson (1994), Software Complexity (CrossTalk: The Journal of Defense Software Engineering).
NIST235
Watson, A. H., & McCabe, T. J. (1996). Strukturerad testning: En testmetod som använder måttet cyklomatisk komplexitet (NIST Special Publication 500-235). Hämtad 14 maj 2011 från McCabe Softwares webbplats: http://www.mccabe.com/pdf/mccabe-nist235r.pdf
SATC
Rosenberg, L., Hammer, T., Shaw, J. (1998). Programvarumått och tillförlitlighet (Proceedings of IEEE International Symposium on Software Reliability Engineering). Hämtad 14 maj 2011 från Penn State Universitys webbplats: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159