Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!rutgers!att!pegasus!psrc
From: psrc@pegasus.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.software-eng
Subject: Re: Software Restructuring
Summary: flow control structures vs. data structures
Message-ID: <2626@pegasus.ATT.COM>
Date: 27 Feb 89 01:23:09 GMT
References: <172@qusunb.queensu.CA>
Organization: AT&T Bell Laboratories
Lines: 46

<"Would you like me to summon Data so he could offer a few dozen synonyms?">

In article <172@qusunb.queensu.CA>, tsitinis@qucis.queensu.CA
(Vaggelis Tsitinis) writes about software restructuring tools, such as
struct (translates unstructured Fortran into structured Ratfor).  There
are several such products on the market, mostly aimed at Cobol.
(Wrinkle up your nose in disgust if you must, but look at it the other
way:  ninty-nine percent of the *ugly* programs companies depend on are
written in Cobol!)

But in languages such as Pascal and C, it's not the flow control
structures that make maintenance programming difficult.  Instead, it's
the data structures.  First and foremost, because they were never
really designed (or even defined) well originally.  Second, because
there's darned little information left on the data design.  Third,
because the data structures have changed over the life of the system,
often in mischievous ways.  (For example, what originally was an
abstract data type has been pried open, and the dependecies on data
representation have grown throughout the system like a cancer.)

Face it; despite the occasional calls for a return to GOTO, flow of
program control is one of the few things we understand about
programming.  WHILE and IF/THEN/ELSE are critical.  Multiple choice
conditionals (SWITCH in C, CASE in Pascal and nearly every other
language) are handy; so are "n-and-a-half" loops, and other ways of
terminating a loop at places besides the top.  If a chunk of code has a
single point of entry and a single point of exit, that code's easier to
read and verify.  The only controversy lies in abnormal escapes other
than the usual exit (RETURN'ing from a subroutine in more than one
place; various kinds of compiler generated exception handling).

To the problem of structuring a program's flow of control, we've come
up with stepwise refinement and top-down design.  (Bottom up has its
proponents for other reasons, but top-down is *a* solution to *this*
problem.)  What's the equivalent for the problem of structuring a
program's data?  Object oriented design seems to be on the right track.
Still, we're a long way from having as final an answer for data
structures as we have for control structures.

> Tsitinis Vaggelis, Department of Computing & Information Science
> Queen's University, Kingston, Ontario, K7L 3N6, C A N A D A
> tsitinis@qucis.queensu.ca 

Paul S. R. Chisholm, AT&T Bell Laboratories, att!pegasus!psrc
psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.