Tue Jul 03 16:00:00 GMT 2001

programming

Subject: Re: Some programming problem of Newbie
Date: 4 Aug 1999 10:59:35 +0100
From: csstjds@brunel.ac.uk (John D Salt)
Organization: Brunel University, Uxbridge, UK
Newsgroups: comp.software-eng

In article <7o8q27$u1p$1@nnrp1.deja.com>,
Carfield Yim wrote:
>I know that it is good to writing pesudo code before implentation.
>But everytime I want to start to write pesudo code, I don't know how to
>start, especially when doing program in visual tools (e.g.:C++ Builder).
>And so I keep in delay and delay, at last, I go back to writing code
>directly after knowing what should I do.
>
>I just wonder, how can I train myself to follow good programming
>practice? Any book can help me?

First of all, I wouldn't worry too much about following your
preception of other people's idea of "good programming practice".
What's "good" is what's good for you, and programming people
have very different individual tastes and practises.

Still, whether you use pseudo-code or not, it's pretty obvious
that you should have some idea what you want to write before
you write it. How much of a "programming plan" do you have
before you dive into code? Do you keep hand-written notes
beside the terminal as you go along? Do you ever make large
changes to what you're coding just to get it to compile?

It also matters what style of programming you're attempting.
If you're using C++ to create object-oriented applications,
I'd say pseudo-code is probably not a good way to get a
clear picture of the overall structure of the program. For
O-O development, restrict pseudo-code to the internals of
individual methods (and many methods will be so simple they
don't need pseudocode at all). Use something like CRC cards
to help you shape the class structures, responsibilities and
interactions.

If you still need to write pseudocode but can't seem to get
started, try some or all of the following:

* Write by hand, not by machine.

* Start with the universal problem-solving Nassi-Schniederman
diagram:

+----------------------------+
| Begin |
+----------------------------+
|| Solve_Problem ||
+----------------------------+
| End |
+----------------------------+

...then refine it incrementally. There's obviously no problem
"getting started" here, as the start step is the same for
everything. Yes, I know it sounds daft, but it works for me.

* Try focusing on the data structures first rather than control
structures first.

* Don't be afraid to throw rough work away, often.

* Take a nip of whisky before you start to get the creative
juices flowing.

It's possible that the programs you're trying to code now are
simple enough that you can see the whole answer in your head
at once. In this case, pseudo-code (or any other design
technique) may seem not to be very useful. If this is the
case, try a problem so big or so hard you can't see the whole
answer (or even the whole problem!) all in one go.

All the best,

John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.


(google search) (amazon search)
1 2 3 second