The first reason hardly requires any explanation. If there is a module for sorting, regardless of what is being sorted, then there is no need to rewrite the code to sort an array, even though in one program we want to sort integers, and in another program we want to sort student records.
The second reason does require some explanation. Because a module must have a defined interface, a module can be tested based on the interface specifications. Software testing is a big subject of its own, and it is out of the scope of this class. However, it suffices to say that it is easier to write test plans when the interface of a module is well defined. Modules do not affect the defects-per-line metric of a programmer, but it does make it easier to locate bugs.
Let's say modules A, B and C are relatively small and easy to verify. Let's say that modules A, B and C are indeed verified. Now, if module D uses A, B and C, and somehow it is not working right, where will you look for the defects? This is why modular programming makes debugging easier, compared to the ``big clump'' approach, which mixes modules A, B, C and D into one intertwined piece of code.
Copyright © 2006-08-21 by Tak Auyeung