How to actually write a program?

[Anna Martelli Ravenscroft]

On Fri, 03 Sep 2004 21:29:36 +0000, Nick Evans wrote:

> Hello there,
> I have been on and off learning to code (with python being the second
> language I have worked on after a bit of BASIC). What I really want to
> know is, if you are going to actually write a program or a project of
> some sort, how do you actually start.
> 
> Picture this, you know what you want the program to do (its features),
> you have a possably rough idea of how the program will work. You have
> opened an empty text file and saved it as 'mykewlprogram.py' and now
> your sitting in front of an empty text file... Now then.... where do I
> start.

Lots of folks have given some great pointers. I'll pass along what I do,
since I'm closer to your level of programming than some folks here.

I usually start by choosing one very simple piece of "what it does"
and trying to code that. Say I want to be able to do x, y and z. I would
start with just trying to make it do x. (Some folks think in terms of data
structures or objects. In which case, start with just creating a very
simple myfirstobject or mydatastruct1.)

The whole test as you go idea is great - I'm working on automating that
more myself. If the whole automatic unittest thing is too advanced for you
for now, just write down a list of manual tests to try -- what's
*supposed* to happen in ? case, and manually try those each time. Don't
forget to think about "what do I do if user enters n instead of x, y or
z". Eventually, you'll use that same kind of question and answer to code a
unittest anyways, so it's actually good practice on working towards
unittesting.

Anyway, I would create a way to test x (or myobject or mydatastruct1), run
(manually or automagically) the test (which fails at first) and then start
working on trying to make x pass, one case at a time. Once x passes, I can
go on to y...

One other tip: add lots of print statements. Print statements are your
friend. They can help you figure out what it's *actually* doing, (and more
importantly sometimes: what it's *NOT* doing) rather than just what you
hope it might be doing. For example, when you start on defining funcx(a),
you could start by having it just print what you gave it for arguments.
You can always comment out or remove the print statements afterwards.

Anna