Making a portion of code into a subroutine is easy. Doing it well, however, is difficult. The following illustrates a very simple application of the concept.

before	after
print "common line of text"; for ($i=0;$i<=10;$i++) { print "the value of i is $i"; }	sub printStuff { print "common line of text"; for ($i=0;$i<=10;$i++) { print "the value of i is $i"; }#end of the for loop }#end of the subroutine

Putting all of that stuff into brackets is very nice and all, but to have the code actually do something, you must invoke the function. That will make the interpreter jump to the location of the subroutine, execute it, then come back to where it was working. Another way of thinking about it (though less accurate) is that the interpreter pastes the code of the subroutine everywhere that you call it. Functionally, however, the two views are the same -- every time you call it, the subroutine gets executed.

The syntax for calling a subroutine is easy -- simply prepend a & to the beginning of the its name. So calling the printStuff function from the previous example would look like:

&printStuff

Calls to subroutines can go anywhere where executable code can be placed, which makes them very useful.

The term arguments refers to data given to a subroutine to process, not a verbal shouting match. Many schools of thought (like what the CS department here teaches) dictate that subroutines should only affect data given to them, leaving all other variables untouched. The merits and downfalls of such a theory belong somewhere else.

To pass arguments to a subroutine, enclose them in parenthesis after the subroutine's name like so:

&SubroutineName(arguments)

The subroutine can then access that information in a special array @_ which holds all the information it has been given. So a routine that printed whatever was passed into it would work like this:

subroutine	calling syntax
sub printArgs { print @_; }	printArgs($variable,"constant");