Procedural code: Difference between revisions
Content deleted Content added
No edit summary |
m oops, typo |
||
| (22 intermediate revisions by 14 users not shown) | |||
| Line 1: | Line 1: | ||
#REDIRECT[[Procedural programming]] |
|||
'''Procedural coding''' is an [[anti-pattern]] that involves building indivisible, monolithic solutions to problems by not factoring out commonalities. |
|||
The main casualties of this anti-pattern are: |
|||
# Re-use: Since the granularity of the solutions are not very fine, it is impossible to re-use one solution to another problem. |
|||
# Readability: In order to understand the problems being solved it is necessary to wade through code, keeping procedural information in mind. |
|||
# Maintainablilty: Changing |
|||
As way of illustration consider the analogy of driving to a destination. The procedural solution is to follow a set of step-by-step driving instructions without using a map. E.g. "turn left at Main Street, go 2 blocks and turn right...". The driving directions are highly context sensitive and of little use to those who do not share the same point of origination and destination. If we lose our place in the instructions we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of analysis is required to get back on course. |
|||
It is impossible to develop a solution without any proceduralism somewhere, the question is where this occurs and how. Most programming paradigms in use today aim to break up the procedures into small re-usable chunks. See [[Object-oriented]] programming for one example of this. |
|||
Another paradigm gaining in commercial popularity aims to break the solution up into two independent stages, a declarative and a interpretive stage. The goal state is declared in one stage, and the actual processes used to arrive at any given goal are left up to the interpretor. In order to handle any permutation the declarative stage might arrive at, the interpretor is forced to break the problem domain down into its natural components. See [[declarative programming]]. |
|||
Latest revision as of 04:59, 5 August 2006
Redirect to: