About / Advertise
Att återanvända källkod blir snabbt lika kostsamt som att skriva om den från noll, om du gör på fel sätt. Här är rätt sätt, enligt Rafael Taubinger på svenska kompilatorjätten IAR.
Att återbruka gammal kod i nya projekt låter som en bra idé att spara utvecklingspengar. Men i verkligheten är det inte gratis. I praktiken kostar det kring 20 procent av att skriva helt ny kod.
Detta enligt Rafael Taubinger, global fältingenjör på IAR.
Siffran 20 procent gäller om du återanvänder koden omodifierad. Vid minsta lilla ändring – vilket görs i hälften av alla fall – skjuter snittpriset upp till 50 procent. Procentandelarna är genomsnitt. Verkligheten kan ligga över eller under. Källkodens kvalitet är avgörande.
Låg kodkvalitet höjer kostnader för både debugging och underhåll. Till debugging går redan 80 procent av utvecklingskostnaderna.
 Denna artikel har tidigare publicerats i magasinet Elektroniktidningen. För dig som jobbar i den svenska elektronikbranschen är Elektroniktidningen gratis att prenumerera på – våra annonsörer betalar kostnaden.Här tecknar du prenumeration (länk). |
Rafael Taubinger ger flera tips hur på kvaliteten kan hållas hög. Det första är enkel psykologi: om den som skriver koden från början har blivit informerad om att koden ska återanvändas – så blir den magiskt av högre kvalitet.
– Precis som du städar mycket bättre när föräldrarna kommer på besök.
Nästa tips är att inte försöka vara smart och hitta kluriga lösningar.
–Det här är ett av mina kanske viktigaste tips! Finurlig kod är svår att förstå och svår att underhålla. Skriv läsbar och begriplig kod istället!
Du kan mycket väl vara fel ute om du försöker handoptimera dina funktioner. Det är inte säkert att den blir så effektiv som du tror. Kompilatorer optimerar nämligen på egen hand. Och de kan vara väldigt duktiga på att göra det, numera. Problemet är att du kan förvirra dem med klurig kod, och så missar de en optimeringsmöjlighet.
Nästa tips är att akta dig för programkod plockad på nätet, så kallad Soup (Software of unknown pedigree). För är den koden testad? Kan den plockas ur sitt sammanhang och sättas in i ditt projekt, som kanske har andra bivillkor?
Följ en kodstandard, som Nasa C, CWE, PC Lint, Misra-C eller Cert! Det är regelsamlingar som förbjuder kod som erfarenhetsmässigt attraherar buggar.
Reglerna säger saker som att du inte ska använda C:s standardtyper eftersom de betyder olika saker för olika kompilatorer, att du ska innesluta alla kodblock i parenteser för att inte luras av layout vart koden egentligen hör, och att du ska begränsa variablers räckvidd i koden för minimera risken för sammanblandning. Införandet av en kodstandard sänkte tvärt andelen buggar med 41 procent, i en studie.
Ett sista tips är att hellre programmera i C++ än C, eftersom det som regel är enklare att återanvända. Språket är konstruerat från start med modernare primitiv för kodåteranvändning än C.
Och så ska du förstås använda automatiska verktyg för kodanalys! Certifiering av kritiska system kräver automatiska analyser från verktyg av detta slag. De ger din kod en extra automattvätt och några fler fula fläckar fulkod försvinner.
Här passar Rafael Taubinger förstås på att göra lite egenreklam för C-Stat och C-Run – IAR:s verktyg för statisk och dynamisk kodanalys. Bland mycket annat kan de upptäcka tvetydigheter i deklarationer och potentiella numeriska överflöden under exekveringen.
Rafael Taubinger höll en föredragning på mässan Embedded Conference Sweden i november i fjol.
