Hi -
> -----Original Message-----
> From: Paul Kraus [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 03, 2003 10:09 AM
> To: [EMAIL PROTECTED]
> Subject: Programs - Flow Charts
>
>
> Does anyone use flow charts to help them with program design. What
> software tools do you use to put down what you want from a program
> before you begin to code. Or even the phases you go through before you
> start to code.
>
> Paul Kraus
>
I am a product of a generation before most of the people
on this list; I began my career in the early 60s doing
Fortran in IBM second-generation mainframes - flowcharts
were a big deal then. (IBM even distributed special flowchart
paper with little boxes on it to help you align your boxes
and diamonds!)
I was never a big fan of the formal side of flowcharting,
but I always did, and still do, believe in the process
of writing down the problem and recursively breaking down
the solution into bite size pieces that can be coded.
Here's what I do:
* Keep a 'journal' of my projects (I use the old fashioned
composition books - the ones with the white flecked black
covers that sell for about $1). I have a series for programming
projects, sysadmin, and one for each computer/network I
administer.
* When I start a new project, I review my programming journal
to see if any previous project applies (quite often this
is the case).
* I write down the problem in it's most basic form in pseudo-
code; a trivial example:
access so-and-so web page
parse html
extract data
load extracted data to database
* I keep refining this pseudo-code until I have pieces that
can be put into code - Perl, C++, whatever.
* I code those pieces one-by-one and, if possible, test
them individually.
* Finally, I glue them together and test the whole package.
I have a friend who is a professional photographer; He once
told me the difference between an amateur and professional
photographer is that the professional throws away all of
his bad pictures, while an amateur puts them in an album.
In the same vein, don't be afraid of throwing away bad
code (or bad approaches to the problem); if you find
yourself tweaking and tweaking a certain routine to get
it to work chances are you have 'missed the boat' and
you should feed the trash can and go back to pseudo-code.
Remember, writing code is a rewarding creative process,
and your style will evolve over time to something you
are comfortable with. It's fun!
Good luck,
Aloha => Beau;
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
