Subprogram
In computer programming, a subprogram is a separate sequence of program instructions that perform a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed. Subprograms may be defined within programs, or separately in libraries that can be used by multiple programs.
| Table of contents |
|
2 History 3 Overview 4 Why use subprograms? 5 Local variables, recursion, and re-entrancy 6 Conventions 7 Related terms and clarification |
The following is an example of subprogram in Ruby.
say_hello
The first use of subprograms was in assembly languages.
A subprogram, as its name suggest, somehow behaves like a computer program. Typically, the caller waits for subprograms to finish and continues execution only after a subprogram returns. Subroutines are often given parameters to refine their behavior or to perform a certain computation with given (variable) values.
In most imperative programming languages, subprograms may have so-called side-effects, that is, they may cause changes that remain after the subprogram has returned. Usually, compilers cannot predict whether a subprogram has a side-effect or not, but can determine if a subprogram calls no other subprograms, or at least no other subprograms that have side-effects. In imperative programming, compilers usually assume every subprogram has a side-effect to avoid complex analysis of exection paths. Because of its side-effects, a subprogram may return different results each time it is called, even if it is called with the same arguments. A simple example is a subprogram that returns a random number each time it is called . Such behavior is invalid in a strict mathematical sense. An exception to this common behaviour is found in functional programming languages, where subprograms can have no side effects, and will always return the same result if repeatedly called with the same arguments. [Note that subprograms are referred to as functions in these languages].
There are numerous motivations for the use of subprograms:
A subprogram may find it useful to make use of a certain amount of "scratch" space; that is, memory used during the execution of that subprogram to hold intermediate results. Variables stored in this scratch space are referred to as local variables, and the scratch space itself is referred to as an activation record. An activation record typically has a return address that tells it where to pass control back to when the subprogram finishes.
A subprogram may have any number and nature of call sites; in fact, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs. This is referred to as recursion, and is a useful technique for making some complex algorithms more comprehensible. However, recursion poses a problem if the recursive execution modifies any local variables, because when the suspended execution resumes, it will find that the data stored in its local variables have been lost.
Early languages like Fortran simply didn't support recursion for this reason. Modern languages almost invariably provide a fresh activation record for every execution of a subprogram; that way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly referred to as stack frames.
If a subprogram can function properly even when called while another execution is already in progreses, that subprogram is said to be re-entrant. A recursive subprogram must be re-entrant. Re-entrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other.
In a multi-threaded environment, there is generally more than one stack. An environment which fully supports coroutines or lazy evaluation may use date structures other than stacks to store their activation records.
The experienced programmers recommend that a subprogram be to perform one and only one task and if not, to split it up into more pieces of subprograms. They argue that subprograms are key components in maintaining code and their role in the program must be distinct.
Some advocate that each subprogram should have least dependecy to other parts of code. For example, they see the use of global variables evil because it adds tight-coupling between subprograms and global variables, if such coupling is not unnecessary at all and advise to refactor subprogram to take parameters instead. This practice is controversial because it tends to increase the number of passed parameters to subprograms.
See programming practice for more details discussion of programming disciplines.
Different programming languages and methodologies possess notions and mechanisms related to subprograms:
Example
def say_hello
print "hello, world\\n"
endHistory
Overview
Why use subprograms?
Generally, to make use of a subprogram, a programmer places some form of call instruction--which constitutes a call site--into an instruction sequence. When the call site is encountered, the instruction sequence is temporarily suspended, and the subprogram itself executes until it completes, at which time the original instruction sequence resumes.Local variables, recursion, and re-entrancy
Conventions
A number of conventions of coding subprogram have been developed. It has been commonly preferable that the name of subprogram is a verb when it does certain task and is adjective when it does some inquring and is a noun when it is used to substitute variables and such.Related terms and clarification
