Procedural code - Revision history

Mckaysalisbury: oops, typo

2006-08-05T04:59:56Z

oops, typo

← Previous revision		Revision as of 04:59, 5 August 2006
Line 1:		Line 1:
	#REDIRECT[[Procedural ~~Programming~~]]		#REDIRECT[[Procedural programming]]

Mckaysalisbury: Moved to redirect (WB:BOLD)

2006-08-05T04:59:22Z

Moved to redirect (WB:BOLD)

← Previous revision		Revision as of 04:59, 5 August 2006
Line 1:		Line 1:
			#REDIRECT[[Procedural Programming]]
	{{unreferenced\|article}}
	In [[computer science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.

	By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.

	The main casualties of this anti-pattern are:
	#Re-use: Since the granularity of the solutions are not very fine, it is difficult to re-apply one solution to another problem.
	#Readability: In order to understand the problems being solved it is necessary to step through code while trying to keep track of the complex state of the world.
	#Maintainability: Since dependencies are highly complex, it is difficult to make a change and know what the outcome will be.
	#Robustness: Since everything depends on everything else, there are an exponentially large number of failure points.

	Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.

	It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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 an interpretive stage. The target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].

	==See also==
	*[[Spaghetti code]]

	[[Category:Anti-patterns]]

DarthVader: {{unreferenced|article}}

2006-08-03T13:44:16Z

← Previous revision		Revision as of 13:44, 3 August 2006
Line 1:		Line 1:
			{{unreferenced\|article}}
	In [[computer science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.		In [[computer science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.

Luna Santin: Reverted edits by 207.200.116.200 (talk) to version 37890429 by Gaius Cornelius using VP

2006-06-26T08:09:38Z

Reverted edits by 207.200.116.200 (talk) to version 37890429 by Gaius Cornelius using VP

← Previous revision		Revision as of 08:09, 26 June 2006
Line 1:		Line 1:
	In [[~~compesuter~~ science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.		In [[computer science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.

	By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.		By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.

207.200.116.200 at 08:09, 26 June 2006

2006-06-26T08:09:24Z

← Previous revision		Revision as of 08:09, 26 June 2006
Line 1:		Line 1:
	In [[~~computer~~ science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.		In [[compesuter science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.

	By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.		By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.

Gaius Cornelius: AWB assisted change "a" to "an".

2006-02-02T20:35:37Z

AWB assisted change "a" to "an".

← Previous revision		Revision as of 20:35, 2 February 2006
Line 13:		Line 13:
	It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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.		It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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 target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].		Another paradigm gaining in commercial popularity aims to break the solution up into two independent stages, a declarative and an interpretive stage. The target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].

	==See also==		==See also==

Nakon: Reverted edits by 65.174.113.6 (talk) to last version by Crenner

2006-01-10T02:32:14Z

Reverted edits by 65.174.113.6 (talk) to last version by Crenner

← Previous revision	Revision as of 02:32, 10 January 2006
Line 1:	Line 1:
		In [[computer science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.

		By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.

		The main casualties of this anti-pattern are:
		#Re-use: Since the granularity of the solutions are not very fine, it is difficult to re-apply one solution to another problem.
		#Readability: In order to understand the problems being solved it is necessary to step through code while trying to keep track of the complex state of the world.
		#Maintainability: Since dependencies are highly complex, it is difficult to make a change and know what the outcome will be.
		#Robustness: Since everything depends on everything else, there are an exponentially large number of failure points.

		Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.

		It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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 target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].

		==See also==
		*[[Spaghetti code]]

		[[Category:Anti-patterns]]

65.174.113.6 at 02:32, 10 January 2006

2006-01-10T02:32:06Z

← Previous revision		Revision as of 02:32, 10 January 2006
Line 1:		Line 1:
	In [[computer science]], '''procedural coding''' is an [[anti-pattern]] that involves solving a problem by incrementally taking somewhat vague steps towards a perceived solution potentially without a full analysis of the desired goals or problem domain. This linear approach often has the effect of producing a monolithic, error prone and un-reusable solution. A counter approach is [[object-oriented programming]]. The polar opposite approach to proceduralism is [[declarative programming]], which starts with the goal and works backwards to find a solution previously conceptualized.

	By way of illustration, consider the analogy of driving to a destination. The procedural solution is to produce 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 we may need to back trace through the instructions to find out where we are. If an unanticipated detour occurs a lot of unnecessary analysis is required to get back on course. Also, one wrong turn could lead to hours of lost time or the inability to arrive at the destination.

	The main casualties of this anti-pattern are:
	#Re-use: Since the granularity of the solutions are not very fine, it is difficult to re-apply one solution to another problem.
	#Readability: In order to understand the problems being solved it is necessary to step through code while trying to keep track of the complex state of the world.
	#Maintainability: Since dependencies are highly complex, it is difficult to make a change and know what the outcome will be.
	#Robustness: Since everything depends on everything else, there are an exponentially large number of failure points.

	Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.

	It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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 target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].

	==See also==
	*[[Spaghetti code]]

	[[Category:Anti-patterns]]

Crenner: include programming in oop link

2005-12-13T17:10:35Z

include programming in oop link

← Previous revision		Revision as of 17:10, 13 December 2005
Line 11:		Line 11:
	Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.		Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.

	It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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.		It is impossible to develop a solution without any proceduralism anywhere using today's computer architectures, the question is where this proceduralism 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 target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].		Another paradigm gaining in commercial popularity aims to break the solution up into two independent stages, a declarative and a interpretive stage. The target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].

Marudubshinki at 07:01, 2 December 2005

2005-12-02T07:01:36Z

← Previous revision		Revision as of 07:01, 2 December 2005
Line 4:		Line 4:

	The main casualties of this anti-pattern are:		The main casualties of this anti-pattern are:
	# Re-use: Since the granularity of the solutions are not very fine, it is difficult to re-apply one solution to another problem.		#Re-use: Since the granularity of the solutions are not very fine, it is difficult to re-apply one solution to another problem.
	# Readability: In order to understand the problems being solved it is necessary to step through code while trying to keep track of the complex state of the world.		#Readability: In order to understand the problems being solved it is necessary to step through code while trying to keep track of the complex state of the world.
	# Maintainability: Since dependencies are highly complex, it is difficult to make a change and know what the outcome will be.		#Maintainability: Since dependencies are highly complex, it is difficult to make a change and know what the outcome will be.
	# Robustness: Since everything depends on everything else, there are an exponentially large number of failure points.		#Robustness: Since everything depends on everything else, there are an exponentially large number of failure points.

	Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.		Note that even if a program is not using [[Object-oriented\|objects]], it does not inherently fall into this trap; likewise programs that use objects can also suffer from the same maladies as procedural software. The anti-pattern only occurs if the modules of the program are not factorable.
Line 14:		Line 14:

	Another paradigm gaining in commercial popularity aims to break the solution up into two independent stages, a declarative and a interpretive stage. The target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].		Another paradigm gaining in commercial popularity aims to break the solution up into two independent stages, a declarative and a interpretive stage. The target state is declared in one stage independent of the solution, and the actual processes used to arrive at any given target are left up to the interpreter. In order to handle all possible permutations of processes needed to arrive at the target states that the various declarative stages might desire, the interpreter is forced to break the problem domain down into its natural components for re-use. See [[declarative programming]].

⚫	[[Category:Anti-patterns]]

	==See also==		==See also==
		⚫	*[[Spaghetti code]]

		⚫	[[Category:Anti-patterns]]
⚫	[[Spaghetti code]]