Gestructureerd programmeren: verschil tussen versies

Verwijderde inhoud Toegevoegde inhoud
k s eraan vast
Regel 4:
Het werd in de [[1960-1969|jaren zestig]] langzaamaan duidelijk dat de omvang en complexiteit van [[Computerprogramma|computerprogramma's]] uit de hand begon te lopen. [[Softwareontwikkelaar]]s zagen door de bomen het bos niet meer. Gestructureerd programmeren en bijvoorbeeld de [[watervalmethode]] werden ontwikkeld om daar iets tegen te doen.
 
Goede programmeurs wisten door gestructureerd te werken code te produceren, die veel gemakkelijker was te doorzien en waarvan de correctheid eenvoudiger was aan te tonen. Het viel op dat bekwame programmeurs vooral veel minder [[spronginstructie]]s, dus veel minder ''GOTO''-statements, gebruikten en veelvuldig gebruik maakten van [[Subprogramma|subroutines]]. Wetenschappers in de [[informatica]], waaronder [[Niklaus Wirth]], [[Edsger Dijkstra]] en [[Michael A. Jackson]], zagen de oplossing in het gestructureerd programmeren, waarbij het door het gebruik van nieuwe constrolestructuren in programmeertalen onnodig zou worden om de onoverzichtelijke sprongopdrachten te gebruiken en de leesbaarheid van de code veel beter werd.<ref>Jackson ontwikkelde een eigen methode, [[Jackson Structured Programming]], om gestructureerd te programmeren.</ref>
Dijkstra probeerde daarbij correctheidsbewijzen van programma's te leveren. Hij is hierin gedeeltelijk geslaagd. Daarnaast werd beoogd parallel werken in grote teams aan grote projecten mogelijk te maken. Dit is door deze aanpak wel gelukt. Een gestructureerde aanpak leidt ook tot [[software]] waarin functies meer afzonderlijk van elkaar zijn gebouwd. Dit maakt onderhoud, zowel correctief als adaptief, aanzienlijk eenvoudiger en minder risicovol.