Subroutines and Modularity

Imagine a program that needs the same job done in three different places. One option is to copy the same lines of code three times. The other option is to write those lines once and let the rest of the program use them whenever they are needed. The second option is the idea behind a subroutine. A subroutine is a block of code that can be called multiple times from different parts of a program.

Before reading on, pause and ask yourself: if a program needs the same calculation or the same printed output in several places, where would you rather keep the instructions for it, in one place or in every place it is needed? The main idea of subroutines is an answer to that question.

A subroutine is a named group of instructions for a specific task. Grouping the instructions and giving them a name is what lets the rest of the program refer to the whole group with a single word. The name serves as a compact substitute for the instructions it represents. When the program reaches that name at a point where it calls the subroutine, the instructions stored under the name are carried out.

Because the same block can be called more than once, one piece of code can serve many moments in a single run of the program. The diagram below traces the control flow for a main program that calls the same subroutine three times. Each arrow pointing to the subroutine is a call, and each arrow pointing back is the return. After each return, the main program continues from the point where it left off.

A large program may need to handle many different tasks. Trying to design all of those tasks as one undivided block makes the program difficult to manage. A subroutine offers a way to separate one task from the rest: its instructions are grouped together, and the group receives a name. This separation is the basis of modularity, the idea that a large program can be divided into manageable units.

Subroutines also change how a programmer approaches a problem. Suppose a program draws a house as one of its tasks. While creating a house-drawing subroutine, attention can stay on drawing the house rather than on every other part of the program. Once that task is organized into a subroutine, the larger design can treat house drawing as an already-solved part of the program. This is what the source means by helping programmers focus on one design problem at a time.

Writing a subroutine once lets the program reuse it at many points, so repeated work does not have to be written out again each time it is needed. The following pseudocode is an illustrative example, not source code. It shows the same drawing job written in three places, first by copying the instructions, then by defining one subroutine and calling it.

The source points to ThreeN2.java as a concrete program that uses subroutines. It is introduced in Section 4.4 as an improved version of the 3N+1 program, and the source describes it as a program that uses subroutines and prints its output in neat columns. The source gives two reasons the program relies on subroutines. The first is code organization: separating work into named blocks makes the program easier to read and manage. The second is output formatting: the subroutines are part of how the results are printed in neat columns.