Structured Coding

I am working on a system that has really ancient code (15 years).  This
was before the time of sturctured code.  Can someone tell me the
reasons why structured coding is BETTER?

On 2 Feb 2006 14:35:50 -0800, "apple.time@yahoo.com"
<apple.time@yahoo.com> wrote:

>I am working on a system that has really ancient code (15 years).  This
>was before the time of sturctured code.  Can someone tell me the
>reasons why structured coding is BETTER?
humm...
looks like homework, and smells like homework.
as such.... please do your homework and search before asking
questions.


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

I have tried to find this out!  But when I get the the real answer, I
have to pay to get it!  This is not for school, but for my employer...

On Thu, 02 Feb 2006 22:47:59 +0000, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>On 2 Feb 2006 14:35:50 -0800, "apple.time@yahoo.com"
><apple.time@yahoo.com> wrote:
> 
>humm...
>looks like homework, and smells like homework.
>as such.... please do your homework and search before asking
>questions.
>

15 years ago was before the time of structured code...

I can see at least one mark being lost before we start here.
--

Ian

<apple.time@yahoo.com> wrote in message
news:1138919750.009976.189420@f14g2000cwb.googlegroups.com...
> I am working on a system that has really ancient code (15 years).  This
> was before the time of sturctured code.  Can someone tell me the
> reasons why structured coding is BETTER?

You have to do something with this code, don't you?

And this spaghetti looks like a real pain in the butt to work with, right?

And it's going to take you many, many hours, which may be translated to
many, many dollars, right?

Now do you understand why structured is better?

MCM

<apple.time@yahoo.com> wrote in message
news:1138919750.009976.189420@f14g2000cwb.googlegroups.com...
> I am working on a system that has really ancient code (15 years).  This
> was before the time of sturctured code.  Can someone tell me the
> reasons why structured coding is BETTER?
>

You have 20 years of cobol experience  (see cobol code assessment post) and
you call 15 year old code ancient?  And you don't know the answer to this
elementary question?  Shocking!

The Grue

My head is full of stuff...  but I cannot find a bulleted list of why
structured code is better.  I personally believe it is better, but I
want to document the many ways for my code assessment, to have evidence
on why the 15 year old code is needing to be retired.  Any help would
be appreciated!  (two heads are ALWAYS better than one!  aren't they?)

"apple.time@yahoo.com" wrote:
>
> I am working on a system that has really ancient code (15 years).  This
> was before the time of sturctured code.  Can someone tell me the
> reasons why structured coding is BETTER?

The least controversial answer is that "structured" coding was done in
accordance with a well-defined set of principles to analyze the problem
before any coding was done.  If the principles were followed then it was
possible to write the program in logical chunks, going from the topmost,
least specific level - in essence the driver loop - through increasingly
detailed decision-making parts, right down to the lowest level where
things were actually done.  All the issues were (in principle) resolved
before any coding was done so the actual coding was a breeze, and
testing turned up fee surprises.  If such principles weren't followed,
the usual result was that the programmer kept remembering or discovering
things that needed to be done as s/he went along, and plugged them in
anywhere in the program.  Thus the logical flow & the relationship
between the various levels was obscured.  Thus there were lots of things
to resolve before the progam went into production, and likely lots of
ongoing error-correction would be needed.

What this really amounts to is that if the program is properly planned
it'll be easy to write and to follow for TPB (the maintenance
programmer).  There were a number of approaches to this: structured
analysis, top down, functional decomposition if you really want to be
posh.

(Now a bit of controversy).

There has been an enormous amount of blather since structured
programming was first written about concerning the GOTO statement.  It's
been blamed for all the ills that programming is heir to.  There are
people, in fact, who define "Structured" programming as "GOTO-less"
programming.   That's nonsense.  Poor program design is the fault in all
cases, not the use of particular verbs or constructs.  It is true that
if you don't use GOTO's, you'll be forced to think about the program and
plan it (perhaps) better, because you can't write it the easy way.  But
a GOOD programmer can write programs with and without GOTO's  and will
produce equal quality work either way.

(End of controversy.  My example follows).

If your 15-year-old code contains GOTO's, don't worry too much about it:
if the programs are hard to follow and maintain it's because they are
badly written, not that they contain GOTO's.  I presented to this group
two examples of my own - 100 programs, 65,000 lines or so, using GOTO's;
the system has now been running since 1996, with only spec changes or
data problems afflicting it; it survived Y2K with no changes needed and
will be going for some years yet.  Another similar system was taken over
by the customer and the only problem they had was that I hadn't given
them the copy books.   (This one was superseded by SAP).  I asked the
group how the situation could be bettered: a stony silence, zero
responses, occurred.

(End of example).

If you are having to cope with a bunch of poorly written programs, about
all you can do is document the file specs, make up cross-references, and
make notes about everything!

PL

apple.time@yahoo.com wrote:
> My head is full of stuff...  but I cannot find a bulleted list of why
> structured code is better.  I personally believe it is better, but I
> want to document the many ways for my code assessment, to have evidence
> on why the 15 year old code is needing to be retired.  Any help would
> be appreciated!  (two heads are ALWAYS better than one!  aren't they?)

Maybe "Structured Cobol Methods" by Noll might help? I no longer have
the book on my shelf, but I believe that it had an introduction which
explained the principles involved. It then went on to develop an
application using these principles. I believe that this was acutally a
variation of what as a Pascal programmer I would call "Top - Down
structured programming." But this was a long time ago in a galaxy far
away....

-- Elliot

"Ian Dalziel" <iandalziel@lineone.net> wrote in message
 news:hg35u1dh9iug5k1oja69a9knbadh0sl5i3@
4ax.com...
> On Thu, 02 Feb 2006 22:47:59 +0000, Frederico Fonseca
> <real-email-in-msg-spam@email.com> wrote:
> 
>
> 15 years ago was before the time of structured code...
>
> I can see at least one mark being lost before we start here.
> --
>
> Ian

Nah, I don't think so.  I remember the concepts being widely discussed as
applicable to COBOL programming before 1978.    I wrote my first COBOL
program that was specifically designed to embody those principles as I
understood them right around then.    Maybe nobody *you* ran around with
around 1990 and before had heard of Structured Programming, but I certainly
knew the term and the associated principles some thirteen years before that!
...

-Chuck Stevens