“In softwareontwikkeling moeten we een aantal goede ideeën weer boven water halen, implementeren en toepassen”, concludeert Jan van Otterloo in zijn reactie op ‘Foutvrij programmeren’.
Een artikel dat begint met “Programmeren is een vak” trekt meteen mijn volle aandacht in deze tijd waarin een ‘cruisecontrol’ van slag raakt in een halfdonkere parkeerkelder, een bus gaat rijden zonder op de bestuurder te wachten en de vrees bestaat dat het aanzetten van een mobieltje een vliegtuig doet neerstorten (‘Foutvrij programmeren’, Computable, 12 maart 2004).
Het artikel was echter een teleurstelling; het suggereert dat als een geneste ‘if-then-else’ er maar typografisch goed uitziet, een programma solide is. Als er toch nog een fout insluipt, haal je die eruit met een ‘stackdump’ (zoals in Java?). Beter zou zijn: een ‘core-dump’ ( net als vroeger, als je zin had aan een puzzel van uren).
De geneste ‘if-then-else’ kwam me bekend voor. Ik heb er een teruggevonden in een Fortran-manual van 1982. Het gegeven voorbeeld komt er dan uit te zien als volgt:
IF( A .AND. B) THEN
…
…
ELSE IF( C ) THEN
CALL D
E= FUNCTIE ( … , …)
IF ( E .EQ. G) CALL H
ELSE
….
….
END IF
Kortom: de overzichtelijkheid van een ‘Case’, maar wel met uitgebreidere vergelijkingsmogelijkheden.
Ideaal
Foutvrij programmeren is al jarenlang een item en bij vlagen ‘hot’. Op een Novi-studiedag werd deze kwestie in 1978 gepresenteerd als ‘Hoe kun je correctheid van een programma bewijzen’. Dat ideaal is nog steeds een ideaal. De wijze waarop het zou kunnen is: een programmacode moet omgezet worden in logica-uitdrukkingen. Dan heeft de wiskunde al programma’s klaar liggen die uit zo’n opeenvolging van logische expressies een conclusie berekent: ‘waar/onwaar’, of ‘klopt/klopt niet altijd’.
Over de weg ernaar toe is wel consenus. Enige van de regels die je dan in acht moet nemen hoop ik nu aan de vergetelheid te ontrukken: werk met modulen; elke module moet in zichzelf gesloten zijn; onderlinge verbindingen zo los mogelijk; binnen een module een zo sterk mogelijke samenhang; en een module moet minimaal beinvloed worden door wat in een andere module gebeurt.
In objectgeoriënteerd programmeren zie ik deze elementen terug. Toch is ergens een verkeerde weg ingeslagen. Dat hangt samen met wat Maas-Maarten Zeeman in zijn reactie ‘Fouten in foutvrij’ (Computable, 2 april 2004) te berde brengt: functionele programmeertalen. Deze hebben “unieke en waardevolle kwaliteiten als het om foutloos programmeren gaat”. Volgens mij is dit het aspect dat een variabele slechts eenmaal een waarde krijgt in een module en deze houdt tot aan de ‘exit’. Bij zo’n exit (of return) wordt bijvoorbeeld alleen de laatste bepaalde waarde aan de ‘caller’ teruggeven en alle andere kandidaat-uitkomsten vergeten, onbereikbaar gemaakt en liefst meteen opgeruimd. In een objectgeoriënteerde taal blijf je op het juiste pad als je als programmeur geen methode maakt/gebruikt die een eenmaal gegeven waarde verandert. Je doet maar een ‘new’ met een kleine wijziging en op weg naar exit wordt bepaald welke (de oude of de nieuwe) teruggeven gaat worden.
Betrouwbaarder
Zeeman noemt ook Algol. Ik kijk terug in mijn cursusboek van 1966 en wordt eraan herinnerd dat een ‘if-then-else’ op de volgende manier wordt gebruikt:
z := if( a< b) then c else ( d+52);
De variabele z is dus altijd gedefinieerd in het vervolg van de betreffende module. In alle andere programmeertalen die ik ken, kun je heel gemakkelijk een variabele in onduidelijke toestand krijgen, met hooguit een waarschuwing van de compiler. Deze Algol-constructie verhindert dat en maakt je programma’s geschikt voor correctheidsproeven. Ook al is zo’n test in de praktijk nog niet te doen, je progamma is nu al betrouwbaarder.
In softwareontwikkeling moeten we een aantal goede ideeën weer boven water halen, implementeren en toepassen. Of het de oplossing is voor de zaken waarmee ik dit schrijven begon, weet ik niet. Maar de totalen en subtotalen op uw energierekening zullen veel vaker gewoon kloppen.< BR>
Jan van Otterloo, Nieuwegein
