Subroutine Parameters and Arguments

Suppose you want a subroutine that prints every value in an integer array in a tidy format: the values separated by commas and enclosed in square brackets. The subroutine has to know which array to print, and the Java way to supply that information is through a parameter. This article looks at what happens when the type of a parameter is itself an array type, so that a whole collection of values travels into the subroutine as one argument.

Read the header from left to right: the word void says the subroutine returns no value, the name printValuesInList identifies the subroutine, and the text inside the parentheses declares one parameter. That parameter has the type int[] and the name list. The brackets after int are what make it an array parameter. Without them, the parameter would accept only one int.

A subroutine cannot be called with an array that does not exist yet. The array must be created and initialized first, and only then can it be passed as the argument. The source illustrates this with a short segment that declares an array variable, creates an array of three integers, fills in its elements and then makes the call. The source itself calls this a legal but not very realistic piece of code, since the array exists only to be handed to the subroutine.

When the call printValuesInList( numbers ) runs, the name numbers appears in the argument position, and the subroutine receives the array as its list parameter. The subroutine does not need to know the name numbers. It works with the array it was given through list, and every reference to list inside the body refers to that array. Only one argument crosses the call, even though the array holds three values.

The diagram shows what is shared. The caller's name numbers and the subroutine's parameter name list are two different names, but both lead to the same array. The subroutine receives that array itself as its argument, which is why the array is the thing that travels across the call, not a copy of its three values listed one by one.

Inside the subroutine, an element is reached by writing the array name followed by an index in square brackets, as in list[i]. The index says which position to read. Positions in Java arrays are numbered starting from zero, so the first value is at index 0 and the last value is at index 2 in a three-element array. The subroutine also needs to know how many positions exist, so it uses the length property of the array. Together these two ideas form the loop that prints the values one at a time.

The length of a three-element array is 3, but the valid indexes are 0, 1 and 2. That is why the loop condition is written as i < list.length rather than i <= list.length. A loop that runs while i is less than the length visits every valid position once and then stops. The loop never names the values 42, 17 or 256. It reads the length and the elements from whatever array it receives, so the same subroutine works for any array of integers.

Trace the output one pass at a time. The first pass prints the opening bracket, then 42 and a comma. The second pass prints 17 and a comma. The third pass prints 256 with no comma, because the comma test fails at the last index. Finally the closing bracket is printed. Combined, the screen shows [42, 17, 256]. The brackets and commas are produced by the explicit print statements in the loop, not by the array, which is exactly why their placement has to be traced.

A useful debugging habit follows the order the source recommends. When a subroutine that takes an array prints something unexpected, first check the call: was the array created and filled before the call? Next check the parameter type. Then follow the loop one pass at a time, watching the index, the length check and the comma test. Most surprises in this subroutine come from one of these places, so tracing them in order narrows the search quickly.