Well, although procedural-oriented programs are extremely powerful, they do
have some limitations.
- Perhaps the most serious limitation is
the tendency for large procedural-based programs to turn into "spaghetti-code".
- Spaghetti code is code that has been modified so many times that the logical flow
shown in the figures above becomes so convoluted that any new programmer coming onto the project
needs a two month prep-course in order to even begin to understand the software
- Why does this happen?
- Well, in reality, a programmer's job has just begun when she finishes writing version 1.0 of
her software application. Before she knows it, she'll be bombarded with dozens of modification
requests and bug reports as users actually get to batter and bruise her poor piece of
- In order to meet the demands of the evil user, the
programmer is forced to modify the code. This can mean introducing new sub loops, new eddies of
flow control and new methods, libraries and variables altogether.
- Unfortunately, there are no great tools for abstraction and modularization in procedural
languages...thus, it is hard to add new functionality or change the work flow without going back and
modifying all other parts of the program.
- Now, instead of
redesigning thework flow and starting from scratch, most programmers,under intense time restrictions
will introduce hacks to fixthe code.
- This gets us to the second
problem with procedural-based programming. Not only does procedural code have a tendency to be
difficult to understand, as it evolves, it becomes even harder to understand, and thus, harder to
- Since everything is tied to everything else, nothing is
independent. If you change one bit of code in a procedural-based program, it is likely that you
will break three other pieces in some other section that might be stored in some remote library file
you'd forgotten all about.
- A final problem with spaghetification,
is that the code you write today will not help you write the code you have to write tomorrow.
Procedural-based code has a tenacious ability to resist being cut and pasted from one application to
another. Thus, procedural programmers often find themselves reinventing the wheel on every new
Previous Page |Next Page
|Procedural-oriented programming is actually very powerful, so don't
let the hype make you think that it has no place in your arsenal of programming
Like libraries, languages, and toolkits, methodologies are just
ways to solve certain sets of programming problems. There is no such thing as an all -powerful
methodology. In some cases, the object-oriented approach will be best suited to your needs and in
others, another methodology might be more appropriate.
PS: A well
written procedural-oriented program can actually be easy to understand. It is just that well
written procedural code is hard to find, especially when 'teams' of programmers, working on multiple
versions are involved. The fact is that procedural languages typically lack the syntactic sugar
necessary to enforce abstraction
Greg Smith sent in the following excellent comments...
It was good to see "Limitations of Procedural-Oriented Programming" but
spagetti is the result of goto'ing all over the place ("goto"ing,
"exit"ing, "leave"ing, "break"ing etc.). The single strand / thread, of
control, whatever, is lost.
Programs written without the abortions of logic can be read, understood,
debugged, etc. in half the time. (a paper witten back in the 60's was the
first recognition of the problem and it outlined the new "structured"
approach which from then on has been the known preffered method).
OOP can offer almost the same benefit on top of that . . . if still, the
rules of structure, are followed, and not the spagetti of goto's, etc.
Unfortunately, all languages still support most, if not all, of the options
for making spagetti out of what could have been structured code. just as
C++ offers the ability to use OOP methods, but does not require it.
(in C the case statement seems to be written so as to nearly require
F I R S T
THE 3 BASIC PROGRAMMING CONSTRUCTS:
1. SEQUENCE consegutive
2. BRANCH if - else
3. LOOP do while
Basics of structured programming:
- there are no goto's, jumps, iterates, etc.
- all loops terminate at the bottom.
((the condition may be at the top))
- there are no infinite loops.
Structured code is easier to write, debug,
and maintain than the "spagetti" world of
goto's, iterates, and exits that preceeded.
Once it was discovered, in the early 60's,
that the time involved in programming could
be cut in half by following the rules given
above, there has been no defensible
justification for doing otherwise, though
S E C O N D - OOP
Object Oriented Programming
is a methodology that gives great importnace
to relationships between objects rather than
implementation details. This distinction is
important and like Structure above, can make
code easier to write and maintain.