De kwaliteit van broncode

Hoe goed is broncode? Hoe goed is een programmeur? Wat is de kwaliteit van het programmeerwerk? Er komen fouten voor, er is slecht werk geleverd. Is er veel gekopieerd? Is het wel oorspronkelijk werk?

Zo maar wat vragen en conclusies over software die al dan niet op maat is ontwikkeld. En vragen waarmee ik in mijn praktijk als gerechtelijk deskundige ICT regelmatig mee wordt geconfronteerd. Nu heb ik in mijn werkzame leven als ICT’er mij de nodige programmeertalen eigen gemaakt: van assembly tot object orientatie, van talen voor data benadering tot webpresentatie en heb ik in al die jaren het nodige aan programmeerwerk meegemaakt: zelf gedaan en van anderen bekeken. En fraaie staaltjes gezien van ‘creatief’ omgaan met broncode en programmeertalen.

De formele definitie

De ISO norm 25010 (sinds 2011 de vervanger van ISO norm 9126) benoemt 13 kwaliteitskenmerken van software: 8 in de categorie kwaliteit van het product zelf (Functionele geschiktheid, Prestatie-efficiëntie, Uitwisselbaarheid, Bruikbaarheid, Betrouwbaarheid, Beveiligbaarheid, Onderhoudbaarheid en Overdraagbaarheid) en 5 in de categorie kwaliteit tijdens het gebruik (Effectiviteit, Efficiëntie, Voldoening, Vrijheid van risico, Context dekking). Nuttige begrippen die zeker helpen om alle aspecten van de kwaliteit van een softwareoplossing als geheel te behandelen. En daar heb ik eerder een blog over geschreven: Wat is kwaliteit van software?

Maar er is meer als je kijkt naar de broncode.

Broncode is een expressie van creativiteit

Programmatuur is bedacht, komt voort uit het brein van een programmeur, er ontstaat iets oorspronkelijks dat de signatuur van de maker draagt. Niet voor niets is er sprake van de auteurswet. En hoewel veel mensen bij programmatuur niet direct aan creativiteit denken, is er bij het maken van een computerprogramma sprake van een creatief proces: er ontstaat iets, bedacht door de programmeur. Aan zo’n creatief resultaat moet je ook eisen stellen, zeker als het gaat om het realiseren van een programma dat als productiemiddel gebruikt gaat worden.

Leesbaarheid als criterium voor kwaliteit

Een belangrijk aspect van de kwaliteit van broncode is leesbaarheid. Leesbaarheid? Kun je broncode dan lezen? Ik zie de vraagtekens op uw gezicht verschijnen. Bestaat er dan zoiets als een leesbaarheidsfactor, zoals dat ook in de “normale” geschreven taal voorkomt?

Ja, die bestaat, ook voor sommige programmeertalen en soms zelfs in de vorm van een geautomatiseerde analyse van de complexiteit van de broncode. En daarbij is er een goede vergelijking met een boek te maken:

• Zinslengte – lengte van coderegels: hoe langer de regel, des te lastiger is het om het verhaal te volgen
• Gebruik van bijzinnen – complexiteit van de coderegels: veel tussenzinnen maken het lastig om de basisgedachte van de zin te blijven volgen
• Moeilijke en makkelijke woorden – het gebruik van programmaconstructies, er zijn verschillende manieren om een boodschap te brengen, complexe constructies doen afbreuk aan de boodschap
• Alinea’s – omvang van de structuren: hoe langer de alinea, des te lastiger is het om de draad te blijven volgen
• Hoofdstukken – omvang van procedures: lange hoofdstukken maken het lastig even met lezen te stoppen en een afgebakend stuk werk te beschouwen
• Plot – Is er sprake van een verhaal dat zich ontwikkeld? Is de plot duidelijk?
• Dikte van het boek – omvang van de bestanden met code: liever geen dik boek maar losse afgebakende delen, zodat je onderdelen op je kunt laten inwerken

En zoals sommige boeken zich makkelijk laten lezen, zo is het ook met broncode: code met kwaliteit laat zich als een goed boek lezen. Maar, wederom geldt de vergelijking met een boek: leesbaarheid is een subjectief begrip, het resultaat van creativiteit, een programmeur heeft het “bedacht” als nieuw en oorspronkelijk werk. En natuurlijk, goede broncode wordt door meer bepaald dan leesbaarheid alleen (structuur, architectuur, complexiteit, functionaliteit, programmastructuur, enz.), maar leesbaarheid is een prima startpunt voor een eerste goede indruk van de kwaliteit.

Leesbaarheid broncode: een pragmatische aanpak

Een goede programmeur gaat er vanuit dat de broncode die hij schrijft, door een ander moet worden gelezen en onderhouden. En in een bijzonder geval kan het de programmeur zelf zijn, maar dan een paar jaar later. Wat praktische suggesties.

• En goede naamgeving is een basis om te starten. Een duidelijke weergave wat een onderdeel doet, een bepaalde routine bereikt, startend met een werkwoord, het doel beschrijvend.
• Een praktisch gebruik van HOOFD- en kleine letters voor de afbakening van de verschillende woorden in een naam, vergroot de leesbaarheid, vergelijk maar eens TOTAALBTWVANALLOFFERTEREGELS, totaalbtwvanalleofferteregels en TotaalBTWVanAlleOfferteRegels.
• Dan in de routines een CHECK: Commentaar, Helder, Elegant, Consistent, Kwaliteitsvol. Het code commentaar moet omschrijven waarom iets gebeurt, niet hoe (want dit volgt uit de code zelf), het commentaar moet toe the point zijn, beperkt, op alle herkenbare plekken voorkomen en iets toevoegen aan de geschreven regels programmacode. Veel programmeertalen en ontwikkelomgevingen hebben een standaard wijze van documenteren, een developer hoort deze te volgen.
• Kies voor een standaard taal voor het schrijven van het commentaar, mijn grote voorkeur is Engels.
• Lange regels tekst zijn lastig te lezen en dat geldt ook voor programmacode. Opsplitsen in regels die altijd korter zijn dan 80 posities.
• Aantal regels in enkelvoudige If/Then/Else constructies: meer dan 30 regels is lastig lezen, opsplitsen in subonderdelen is de oplossing
• Meervoudig geneste If/Then/Else constructies geven een slecht overzicht: meer dan 2 of 3 niveaus is ongewenst, opsplitsen kan altijd.
• Aantal regels code in een procedure: mijn praktische limiet is 1 bladzijde, dus maximaal 60 regels. Ook hier weer geldt: opsplitsen kan altijd.

Moderne ontwikkelomgevingen bieden de programmeur gereedschappen om al haast vanzelf aan deze richtlijnen te voldoen en beiden hulpmiddelen de code te herstructureren om het beter leesbaar (en daarmee ook beter onderhoudbaar) te maken (refactoring). Voorwaarde is wel dat de programmeur het gereedschap goed kennen en beheersen en daar mankeert het nog wel eens aan!

Leesbaarheid bewaken

Een praktische methode om de kwaliteit en consistentie van broncode gedurende het ontwikkeltraject te waarborgen is source code reviews: liefst dagelijks. Programmeurs bekijken code van elkaar en gaan na of de code leesbaar is, conform de afgesproken richtlijnen en begrijpelijk is. Ook een source code review door ervaren buitenstaanders kan zeer verhelderd en leerzaam zijn.

Niet alleen wordt hiermee de kwaliteit van de broncode positief beïnvloed: ook leert men van elkaar en dat is minstens zo waardevol! En deze waarde komt in de loop van de levensduur van programmatuur naar voren, want 70% van de investering zit in onderhoud van programmatuur en niet in nieuwbouw.

Goede kwaliteit (leesbaarheid) van programmatuur betaalt zich dubbel en dwars terug.