12-03-2004 Foutvrij programmeren
Programmeren is een vak,  . . . 
. . . .  Gezien eenieders ervaringen van de afgelopen jaren lijkt het misschien onmogelijk om foutvrije applicaties te bouwen. 'Application control programming' (acp) biedt echter wel degelijk de mogelijkheid om deze schijnbare utopie te realiseren. MARTIJN LINSSEN
 
02-04-2004 Fouten in 'foutvrij'
Voor Maas-Maarten Zeeman bevatte het artikel Foutvrij programmeren' van Martijn Linsen een aantal onduidelijkheden. Volgens hem maakt de auteur zelfs enkele fouten.
 
16-04-2004 Betrouwbaarder programmeren
"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'.
 
 Opinie & Discussie | 16 april 2004 | nr 16 | pag 35 | redactie@computable.nl


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).

____________________________

  IF( A .AND. B ) THEN
    ...
    ...
  ELSE IF( C ) THEN
    CALL D
    E= FUNCTIE( ... , ... )
    IF( E .EQ. G ) CALL H
  ELSE
    ...
    ...
  END IF
____________________________
De geneste if-then-else kwam me bekend voor. Ik heb er een teruggevonden in een Fortran-manual van 1982. Het voorbeeld uit het artikel komt er dan uit te zien als volgt:


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 beïnvloed 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 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.