Modular programming works on the principle of "divide and conquer." It’s worth sorting out.
Modular programming involves organizing a program as a set of independent blocks of small sizes, which are usually called modules, the behavior and structure of which are completely subordinate to well-defined principles. It is worth dividing the application of the concept of “module”, when in view of it there is a syntactic unit of a programming language and when it is said about the unit of fragmentation of a large program into several blocks, which can be implemented both in the form of procedures and in the form of functions. The use of modular programming makes it possible to simplify program testing and the timely detection of errors. It is possible to strictly separate hardware-dependent tasks from other subtasks, which will improve the mobility of created programs. Time-critical modules can be redone separately, which greatly simplifies the process and makes the efficiency much higher. In addition, modular programming is much easier to understand, since modules can be effectively used as building blocks in other programs.
The term “module” itself began to be used in programming in connection with the introduction of the modular principle in writing programs. In the seventies, a module was called a function or procedure that was written according to certain rules. Since at that time no universally accepted requirements were formed, the module called any procedure whose size was up to fifty lines. Parnassus formed the first specific requirements for the module: "For the formation of one module, the most minimal knowledge about the content of another should be enough." It turns out that it was Parnas who first formed the concept of information hiding in programming. Its definition leads us to the fact that a module can be called any separate procedure of both the lowest and highest levels of the hierarchy. Reliably hiding information could not be ensured through the use of constructions existing at that time, since they were subject to the strong influence of global variables, and their behavior in complex programs is very difficult to predict. It was necessary to create a construct isolated from these variables. It was she who was called the module, and on its basis modular programming was born.
Initially, it was assumed that the implementation of complex software systems can be carried out using the module along with functions and procedures as a construct that unites and hides the implementation details of a particular subtask. But Turbo Pascal did not fully implement the modular programming principle. Support for internal modules is completely absent in this language; import is not implemented flexible enough, since it does not allow importing objects from some other modules. The combined influence of this circumstance with the fact that with the spread of personal computers the range of programming people expanded significantly, which reduced the average level of theoretical preparedness, led to the fact that, when developing applications, the modules were used as a means of creating problem libraries of functions and procedures. Only qualified programmers used the full power of this language construct for operations to structure all objects.
If you look at Pascal modules from the programmer’s point of view, their number should be determined by decomposing the task into a number of sub-tasks that are independent of each other. In the extreme case, the module can be used to conclude in it only one procedure, if it is required that the local action that it performs is completely independent of the influence of other parts of the program when changes are made to the project code.