pas changé rapidement leur idée de la modularité pour adopter la plus grande atomisation que permettent les procédures.

La modularité dans le sens RPG traditionnel, fondée sur la sous-routine, a abouti à des sous-routines qui n’étaient pas aussi petites et ciblées que le prévoyaient les théoriciens de la programmation modulaire. Peut-être en raison de la nature du langage luimême et des limitations de la sous-routine, les développeurs RPG ont hésité à écrire de petites sous-routines ciblées. Mais, dès lors que les procédures existent, ces mêmes développeurs RPG devraient viser un plus grand degré de modularité.

La haute modularité bénéficie à la compacité de compréhension, en permettant à un nom de procédure (ou appel de sous-routine) de prendre la place d’un bloc de code de telle sorte que le bloc de code appelant puisse lui-même être plus compact, plus clair et plus ciblé. Chaque module est condensé et compréhensible et, si vous utilisez des noms autodescriptifs pour les procédures (ou sous-routines), les lecteurs pourront le plus souvent comprendre le module appelant sans se référer au module appelé.

Signalons au passage que la haute modularité conduit à une ségrégation ou « hiérarchisation » des modules : les modules de contrôle de processus étant aux niveaux supérieurs, les modules fonctionnels aux niveaux intermédiaires, et les modules d’I/O aux niveaux inférieurs. Cette approche de hiérarchisation par type de module peut aider à la conception des programmes.