Defining and Calling Subroutines

Subroutines, the reusable blocks of code that perform a task, often need outside information to do their work. Parameters are the mechanism that carries that information in. This article works from one line of source code, a call to a subroutine named doTask, and uses it to separate the two kinds of parameter you will meet throughout this topic.

Imagine a program that needs the same job done in three different places. You could copy the same lines three times, or write those lines once and let the rest of the program use them whenever they are needed. A subroutine is the second option: 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, would you rather keep the instructions in one place or in every place they are needed? Hold that question in mind, because the main idea of subroutines is an answer to it.

The important word in the definition 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 one run of the program.

The diagram shows one subroutine definition serving two call sites. The definition exists once. Each call is a separate moment in the run, and each moment can supply different values. The source states that a subroutine runs when the program calls it, which is why writing it once lets the program reuse it at many points. Once the subroutine finishes, control comes back to the program at the point of the call, so the main program can carry on with the next line after each call.

An actual parameter is a value or expression passed to a function when it is called, and it appears inside the parentheses of the call. In the call doTask(17, Math.sqrt(z+1), z >= 10), there are three actual parameters. The first is a plain value, 17. The second is an expression, Math.sqrt(z+1). The third is a comparison, z >= 10. Each is supplied in a fixed position, and the order of the list matters.

The call supplies its three actual parameters in a fixed order, and the subroutine receives them in the order they appear in the call. The formal parameter slots in the diagram are generic positions. The source pack shows the call to doTask but not its definition, so the names of doTask's formal parameters are not given here. What you can rely on is their role: each formal parameter is a placeholder inside the definition that stands for a value supplied later by whoever calls the subroutine.

An actual parameter is not always a plain value. The expression Math.sqrt(z+1) and the comparison z >= 10 must each be worked out before anything reaches the subroutine. The program first evaluates z+1, passes that result to the square-root operation, and then passes the single resulting value into the call. The comparison z >= 10 similarly becomes one value before the call proceeds. The subroutine never sees the expression itself, only the value it produced.

The source gives a practical rule for unexpected results: when a result diverges, check the call's actual parameters one by one before looking inside the subroutine. Start at the call, write down the value each actual parameter should have based on your reading of the call, and compare that with what you expected.

The source 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 the use of 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.

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. Each call you find is a point where the main program hands work to a subroutine and then continues.