Writing Loops Inside Subroutines

This article starts with a subroutine rather than a list of rules. The subroutine prints a 3N+1 sequence. The number the sequence starts from is not written inside the subroutine. Instead, the caller supplies that number each time it calls the subroutine. As you read, keep one question in mind: when the subroutine runs, where does its starting number come from, and at what point does it first have a value?

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.

The subroutine in this article is declared with a parameter list in its header. The header is static void print3NSequence(int startingValue). The part in parentheses is the parameter list. It says that the subroutine expects exactly one parameter, and that the parameter is of type int. The number and types of the parameters in this list tell any caller what must be supplied.

Read the header from left to right to find what a caller needs. The name tells the caller which subroutine to invoke. The type in the parameter list, int, tells the caller what kind of value must be supplied inside the parentheses. The parameter name, startingValue, is the name the body will use for that value. The caller does not need to know this name to make the call, because the value is passed in by position.

The definition does not give the parameter a value. The value comes from the call statement. When the computer executes a subroutine call statement, it first assigns the value supplied in the call to the parameter name, and only then executes the statements of the subroutine body. The parameter name can then be used inside the body in the same way as a variable name.

The timing is the key point. The assignment to the parameter happens before the first statement of the body, which is why the body can rely on the parameter already holding a value. If you want to know what the body sees on its first line, the answer is always the value the call supplied.

A main program can call the same subroutine at several points in its run. Each call is a separate event. Control leaves the main program, enters the subroutine, runs the body with that call's value, and then returns to the point where the call was made. The sequence below uses the two calls from the driver plus one additional call with a different value to show the pattern.

Notice that each call starts the body fresh with its own supplied value. The first call supplies 17, the second supplies the current value of K, and the third supplies 12. The same definition is used every time, and only the value assigned to startingValue changes between calls.

When a parameterized subroutine produces a wrong result, you can narrow down the cause by following one path in order. First, identify the value supplied by the call. Second, check its assignment to the parameter. Third, check the body's first use of that parameter. The step where the value first differs from what you expected is where the problem begins.

The source points to ThreeN2.java as a concrete program that uses subroutines. It is introduced 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 does not list the individual subroutines inside ThreeN2.java or show their code, so this article does not describe them in detail.

The source gives two reasons ThreeN2.java 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 program prints its results in neat columns, and the subroutines are part of how that formatting is achieved. 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.