Designing Subroutines to Solve Subtasks

Imagine a program that needs the same job done in three different places. You could copy the same lines of code three times, or you could write those lines once and let the rest of the program use them whenever they are needed. A subroutine is the second option. It is a block of code that can be called multiple times from different parts of a program.

The important word is called. A subroutine does not run just because it exists in a program. It runs when the program reaches a point where it calls it. Because the same block can be called more than once, a single piece of code can serve many moments in a single run of the program.

Subroutines are easiest to understand when you watch one do a concrete job. This article uses one small task: given a positive whole number, print every number that divides it evenly. The task is narrow on purpose. It has one input, one loop, and one decision, so every line of the subroutine has a clear reason to exist.

The task is also only a piece of a larger program. A program is assembled by breaking a big problem into subtasks, and each subtask becomes a subroutine. Writing the subroutine is one half of the work; deciding which subtasks deserve their own subroutine is the other half. This article concentrates on the first half.

Before you look at the program's behavior, pause and form a prediction. Suppose a caller passes the number 12 to the subroutine. Which numbers should appear on the screen, and in what order? Write your answer down, including whether the first line of output is something other than a divisor.

Every subroutine header follows one template: modifiers, then a return type, then the subroutine name, then a parameter list in parentheses, and finally a body in braces. Writing a subroutine means filling in each slot of this template. The header of the divisor program fills the slots in a specific way.

The modifier is static because the course is working only with static subroutines at this stage. An access modifier such as public or private could be added, but nothing in the task asks for one, so it is left out. The parameter list holds a single entry, an int named N, which represents the given integer whose divisors should be printed. The names N and printDivisors were not given by the problem; the programmer chose them.

The return-type slot describes what, if anything, the subroutine hands back to its caller. The divisor task says only to print the divisors, not to compute and return a value. A subroutine that does not return a value uses void in that slot. The printing happens as a side effect of running the body, and the caller receives nothing back.

The body is written from a plain-language algorithm: for each possible divisor D in the range from 1 to N, if D evenly divides N, print D. The phrase that matters is in the range from 1 to N. The loop variable D starts at 1, is tested against N before each pass, and is increased after each pass. Every candidate is checked exactly once, in increasing order.

The diagram shows the two decisions that control the output. The loop test decides whether another candidate is examined at all. The divisibility test decides whether a candidate is printed. Every path either prints a value or skips it, then moves to the next candidate, which is why the loop never needs any extra bookkeeping. For N = 12, the values 1, 2, 3, 4, 6, and 12 are printed, and the values 5, 7, 8, 9, 10, and 11 are skipped.

The contract also settles who is responsible for what. The subroutine trusts its input, and the caller must make sure the assumption holds before making the call. If the caller breaks the contract, the subroutine is not obligated to produce a sensible answer, and the fault lies with the call site rather than inside the body.

A subroutine runs when the program calls it, so writing it once lets the program reuse it at many points. The main program below calls printDivisors three times. Each call causes control to leave main, jump into printDivisors, run the body from start to finish, and return to the line after the call.

The control flow makes the reuse concrete. In one run, the program leaves main three times and enters printDivisors three times. Because the subroutine returns nothing, each return simply resumes main at the next line. The subroutine never needs to know which call invoked it; it only reads the value of N it was given.

Suppose you expected the divisors of a number to appear in order, but the list stops short of the number itself. A reliable way to find the cause is to follow the loop by hand for that one input. Start with the header, then test each candidate D against the loop bound and then against the divisibility condition, noting every decision. The first point at which your hand trace and the actual output disagree is the failure location.

Hand-tracing works because the body has only a few steps. Compare your trace to the output one line at a time. If the first disagreement appears at a candidate that should have been printed, look at the divisibility test. If the output stops before the largest candidate was tested, look at the loop bound. The earliest mismatch points to the step that produced the unexpected value.

The source material points to a concrete program that uses subroutines: ThreeN2.java. 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 for this design. 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.

The source does not list the individual subroutines inside ThreeN2.java or show their code, so this article does not describe them in detail. When you open the file yourself, look for the places where the program calls a named block of code, and compare them with the places where it prints results. Those call sites show how the subroutines organize the program.