On Mon, 30 May 2005, Andrei wrote:
> . , <administrata <at> hotmail.com> writes:
>
> > But, I don't know how to plan a prog. with algorithm.
>
> For small programs there's little value in planning - in fact, you'll
> probably end up wasting time. As far as individual algorithms go, it's
> usually best to go with whatever seems the easiest to understand and
> only do more advanced things once you know that you need more speed or
> something like that.
I'm not sure about this, but I think we might be using the word
"algorithm" a bit flippantly. *grin* I think we might be talking more
about designing programs in general.
Some design advocates say that program design should be a part of every
program. At least, at minimum, we may want to think about:
1. What is the program supposed to do? What's the input, and what's
the output?
2. What would a typical program run look like?
3. What can we test it with to know that the program's doing the right
thing?
For example, if we're trying to write a program to capitalize a name, we
might want to "design" it as:
The program takes a string, and returns a capitalized version of that
string. For example, capitalize("john adams") --> "John Adams", and
capitalize("elvis") --> "Elvis". I don't know what to do if we get
a non-name string, so let's just leave those cases alone.
i.e. capitalize("42") --> "42".
At least, at minimum, we should do enough thinking to let us know if we're
going astray as we write our program. *grin* A big problem in writing
programs is not recognizing when they don't work, which is why Unit
Testing is getting so much attention these days.
The textbook "How to Design Programs" focuses on a design approach to
program construction. The book's host language is Scheme, but I feel a
lot of the material is language agnostic and valuable to any programmer:
http://www.htdp.org
Best of wishes!
_______________________________________________
Tutor maillist - [email protected]
http://mail.python.org/mailman/listinfo/tutor
