Formal Parameters and Passing Values to Subroutines

Before reading the rest of this article, try a short thought experiment. Suppose a caller has a whole-number variable holding the value 5 and passes it to a subroutine. Inside the subroutine, the parameter is increased by 10. Once the subroutine returns, what does the caller's variable hold? Decide on your answer before you continue.

The answer surprises many beginners because they assume that every name inside a subroutine is connected to the rest of the program in the same way. That assumption leads to predictable mistakes. This article sorts out which names a subroutine can reach, which of those names can influence the caller, and why the answer depends on where each name was originally declared.

A subroutine can work with three different kinds of variables. The first is a local variable, which the subroutine declares for its own use. The second is a formal parameter, which is the name in the subroutine's header that receives a value from whoever calls it. The third is a variable declared outside the subroutine, which the subroutine can still reach. The source describes this third kind as a static member variable declared outside the subroutine.

These three categories differ in two ways: where their names come from, and how far their effects travel. Parameters and locals are both created for the subroutine when it runs, while the outside variables already existed before the subroutine was called. That single difference, whether a name belongs to the subroutine or to the wider program, explains most of the behavior in the rest of this article.

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: 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 one run of the program. The diagram below traces a main program that calls the same subroutine twice; control leaves main, runs the subroutine, and returns to main each time.

Read the diagram from top to bottom. The subroutine's instructions are written once, but they execute twice, because each call starts a fresh run of that block and each return hands control back to the line of main that follows the call.

The consequence for primitive types is direct. When the subroutine is called, the caller's value is dropped into the parameter name. Once execution of the subroutine begins, that parameter behaves much like a local variable. A change made to it inside the subroutine has no effect on the rest of the program, so the caller's variable keeps whatever value it had before the call.

The source adds an important qualification: the situation is more complicated for arrays and objects, which it promises to treat later. This article limits itself to primitive types, where the rule above holds cleanly. The diagram below shows the parameter as a separate box that receives a copy of the caller's value.

The changed value 15 exists only in the subroutine's parameter. The caller's x is still 5 when the subroutine returns, because the update was made to the parameter's own value, not to x.

A global variable behaves differently from a parameter because it was never copied into the subroutine. It already existed outside the subroutine and is shared with other parts of the program. When the subroutine changes it, the change is visible wherever that variable is read afterward. The before-and-after diagram below shows a shared counter changing during one call.

Notice that main never passes count into bump. The effect travels outside the subroutine through the shared variable, which is exactly what makes global variables powerful and also what makes them easy to misuse.

Using a global variable inside a subroutine makes that variable part of the subroutine's interface. The subroutine communicates with the rest of the program through the shared variable, not only through its parameter list. The source describes this as a kind of sneaky, back-door communication. It is less visible than communication through parameters, and it works against the goal of a black box whose interface is straightforward and easy to understand.

The source is careful not to forbid the practice. Global variables are not always bad inside subroutines. If the global variable is treated as part of the subroutine's interface, the communication is acceptable. Before using one, ask whether it is really necessary. If a value can be passed in as a parameter and returned or used directly, that is usually the more visible choice; a shared variable is reasonable when the design deliberately makes it part of the interface and the reason for sharing is clear.

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. This makes it a good place to see the idea in an actual program rather than only in the abstract.

The source gives two reasons that 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.

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 those calls with the places where it prints results. Each call you find is an instance of the reuse pattern from earlier in this article.