Compiler

• Een zegen roept de één, Een compiler maakt het makkelijker om kwaliteitsoftware te maken., want de compiler haalt al veel fouten uit de code voordat het programma loopt. Ja, waar. Vooral voor syntax- en spelfouten zijn compilers een zegen.
• Een compiler dwingt je om alles goed uit te denken, voordat er ook maar één statement van het programma loopt. Hmm. Is dat echt zo'n voordeel?

  Een lange mars begint met een eerste stap. Graag zou ik die eerste stap testen voor dat ik aan de tweede begin. Twee maal de helft is makkelijker dan één maal het geheel.

• Dipje is dat de compiler zich beperkt tot syntax en logische fouten, geen weet heeft van runtime-waarden. Java-objecten in een Vector zijn berucht om hun ClassCastExceptions (java.sun.com/.../ClassCastException...).

1. Eerst de methods op hoog niveau schrijven. Die roepen, nog niet bestaande, lagere methods op.
2. De software loopt natuurlijk in een foutmelding. Dat is zelfs de bedoeling. In de debugger kan ik kijken of alles tot zover naar wens is. Pas dan schrijf ik één dieper liggende methode, die nog diepere methodes aan zal roepen.

   Een interpreter geeft me de kans om de geest te focussen op één tak, het groene gedeelte in de boom hiernaast. Die tak kan ik apart testen, voordat ik hoef na te denken over alle andere takken.

3. Uiteindelijk komt de bodem in zicht, zoals getters & setters. Dan werkt alles, van top tot teen.

• Deze top-down-depth-first methode werkt efficiënt. Alleen de methodes die echt nodig zijn en nog niet bestaan, vragen ontwikkeltijd.
• De top-down-depth-first methode verhoogt bovendien de kwaliteit van de software. Door de tussentijdse debug inspecties weet ik zeker dat het programma op hoog niveau goed in elkaar zit, voordat ik tijd spendeer aan lagere methods. Sommige methodes zijn herbruikbaar in andere takken, getest en wel.

Tot de volgende week,
Henk Jan Nootenboom