Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!udel!rochester!cornell!uw-beaver!microsoft!alonzo
From: alonzo@microsoft.UUCP (Alonzo Gariepy)
Newsgroups: comp.software-eng
Subject: Re: Basics of Program Design
Message-ID: <1559@microsoft.UUCP>
Date: 25 Jun 88 10:00:51 GMT
References: <900@td2cad.intel.com> <3537@pdn.UUCP>
Reply-To: alonzo@forward.UUCP (PUT YOUR NAME HERE)
Distribution: na
Organization: Microsoft Corporation, Redmond, WA
Lines: 75

In article <3537@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes:
>In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes:
>>What I mean is: do experienced programmers usually write flow charts,
>>or pseudo code. Do they write the whole program out by hand first or
>>build it up in their favorite editor?
>
>Flow charts or state diagrams (I prefer the former) are better thought 
>organizers, but are difficult to maintain, so pseudo code usually wins out.
>However, with flow charts it is difficult to forget about a path.  Does 
>ANYONE write code by hand, anymore?  I doubt it.
>

I do.  Write code by hand sometimes, that is.

I tend to design solutions before I design a computer system.
Then I design a computer system, and then the program.

The externals of a program have to be established before you start
to design the code.  I generally design the code from the top, down.
This gives me some idea of the kind of primitives I need and allows
the functions of the program to be modularized.  I can identify
similar tasks that can be merged into single routines (although
I favour small routines, and many are called only once).  I work
my way down to designing the primitives of the system and identifying
tricky algorithms and data structures.

I start implementation with the primitives, tricky algorithms and data
structures.  This is where I use paper.  The best form of data structures,
the most suitable algorithm and implementation, and the correct behaviour
and choice of primitives are all interdependent.  I tend to sketch these
things out on a narrow lined pad with a pencil.  The tricky algorithms
I often actually code on paper, especially if I have decided that they
need to be coded in assembler.  Obviously, few programs have very
many tricky algorithms.  I often use the same tools when putting together
an ADT (abstract data type).  Perhaps I work on these things best in an
organic environment, as opposed to with a vdt in my face, a disk and fan
in my ears, and a handfull of keyboard.

I don't normally work out the fine points of the top level design until 
I have done the implementation described above.  The majority of most 
programs is control structures, initialization, error handling, i/o, etc.
These things are usually very straightforward and I code them directly
into the editor with comments.  Keeping routines small puts more emphasis
into the design and allows for fewer oversights in coding.  My main() 
routine typically contains only procedure calls with perhaps one or two 
loops and if statements.  Sometimes, when I don't yet know how to do
something, I put a comment in instead.  

The important thing is to know the inputs and outputs of procedures
that do transformations on data, and know the mission of procedures
that have large side effects.  I only use flow charts for designing
the flow of information, never for the flow of control.  State tables
are useful for state driven programs, if you are forced to use an
operating system so primitive that it doesn't have multitasking
cheap enough to replace a state model.  My feeling is that
if understanding the flow of control ever becomes a problem, you have
made a major design error and should start over.  

In multi-process programs, complex control flow is replaced by complex 
message passing.  This can become a nightmare if you haven't chosen a 
good model for process design.  With cheap enough multitasking, it makes
sense to keep processes small and focused the same as you do with
procedures.  Proper error handling and resource control in very complex
programs dominates many other design and coding considerations.

It seems to take many years of hard earned pain before you realize that
most useful programs will have added to them new features, a new interface,
new machines to run on, etc.  It becomes worth the effort to do clean
designs up front that save you the agony of patching up bad code later.

And let me tell you, bad coding is universal...

Alonzo Gariepy

Net disclaimUsual