Procedural programming

From Wikipedia, the free encyclopedia

This article or section does not cite its references or sources.
You can help Wikipedia by introducing appropriate citations.

Procedural programming is sometimes used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions (not to be confused with mathematical functions, but similar to those used in functional programming) simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself.

Procedural programming is often a better choice than simple sequential or unstructured programming in many situations which involve moderate complexity or which require significant ease of maintainability. Possible benefits:

The ability to re-use the same code at different places in the program without copying it.
An easier way to keep track of program flow than a collection of "GOTO" or "JUMP" statements (which can turn a large, complicated program into so-called "spaghetti code").
The ability to be strongly modular or structured.

1 Procedures and modularity
2 Comparison with imperative programming
3 Comparison with object-oriented programming
4 Procedural programming languages
5 See also
6 External links

[edit] Procedures and modularity

Especially in large, complicated programs, modularity is generally desirable. It can be achieved using procedures that have strictly defined channels for input and output, and usually also clear rules about what types of input and output are allowed or expected. Inputs are usually specified syntactically in the form of arguments and the outputs delivered as return values.

Scoping is another technique that helps keep procedures strongly modular. It prevents the procedure from accessing the variables of other procedures (and vice-versa), including previous instances of itself, without explicit authorization. This helps prevent confusion between variables with the same name being used in different places, and prevents procedures from stepping on each other's feet.

Less modular procedures, often used in small or quickly written programs, tend to interact with a large number of variables in the execution environment, which other procedures might also modify. The fact that lots of variables act as points of contact between various parts of the program are what make it less modular.

Because of the ability to specify a simple interface, to be self-contained, and to be reused, procedures are a convenient vehicle for making pieces of code written by different people or different groups, including through programming libraries.

(See Module (programming) and Software package.)

[edit] Comparison with imperative programming

Most or all extant procedural programming languages are also imperative languages, because they make explicit references to the state of the execution environment. This could be anything from variables (which may correspond to processor registers) to something like the position of the "turtle" in the Logo programming language (which could be anything from a cursor on the screen to an actual device which moves around on the floor of a room).

Some imperative programming forms, such as object-oriented programming, are not necessarily procedural.

[edit] Comparison with object-oriented programming

Please expand this section.
Further information might be found on the talk page or at Requests for expansion.
Please remove this message once the section has been expanded.

The focus of procedural programming is to break down a programming problem into a collection of data structures and routines.
The focus of object oriented programming is to break down a programming problem into objects.

It seems that either method can be valid for accomplishing a specific programming task.

[edit] Procedural programming languages

To be considered a procedural, a programming language should support procedural programming by having an explicit concept of a procedure, and a syntax to define it. It should ideally support specification of argument types, local variables, recursive procedure calls and use of procedures in separately built program constructs. It may also support distinction of input and output arguments.

The canonical example of a procedural programming language is ALGOL. A language in which the only form of procedure is a method is generally considered object-oriented rather than procedural, and will not be included in this list. This applies to C# and Java, but not to C++.