How to actually write a program?

[Nick Evans]

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.

Any ideas about this problem :-)

Ta
Nick

[Ksenia Marasanova]

> Any ideas about this problem :-)

I dont' know if this is a 'right' approach, but if the program has user
interface, it helps also first to create this user interface. That way
you'll be able to visualize what information your program needs to get
and to send back. It can be easier then to define classes and
methods...

Ksenia.

[Michael Hudson]

"Nick Evans" <ni**@huff.org. uk> writes:

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.

Any ideas about this problem :-)

In addition to what others have said, I use the interactive
interpreter A LOT (probably too much; I should write more tests).

Cheers,
mwh

--
... the U.S. Department of Transportation today disclosed that its
agents have recently cleared airport security checkpoints with an
M1 tank, a beluga whale, and a fully active South American volcano.
-- http://www.satirewire.com/news/march02/screeners.shtml

[Ville Vainio]

>>>>> "nick" == Nick Evans <ni**@huff.org. uk> writes:

nick> have a possably rough idea of how the program will work. You
nick> have opened an empty text file and saved it as
nick> 'mykewlprogram. py' and now your sitting in front of an empty
nick> text file... Now then.... where do I start.

Typically, a program reads a bunch of data, crunches it and outputs
it. Find a trivial way to get the necessary data into elementary
Python data structures like lists, tuples and dicts (many typical
programs don't need classes at all). Write a function to process that
data, resulting in a bunch of new objects (data
structures). pprint.pprint the resulting objects, and after you are
satisfied with the output, perform the necessary actions according to
the objects. The rest is just chrome.

If you are interested in starting with the chrome (a'la VB), check out
PythonCard (or Boa constructor, or equivalent).

--
Ville Vainio http://tinyurl.com/2prnb

[Peter Kleiweg]

Ksenia Marasanova schreef:

Any ideas about this problem :-)

I dont' know if this is a 'right' approach, but if the program has user
interface, it helps also first to create this user interface. That way
you'll be able to visualize what information your program needs to get
and to send back. It can be easier then to define classes and
methods...

I disagree. In that case, better to define the data structures
you're program is going to manipulate.
--
Peter Kleiweg L:NL,af,da,de,e n,ia,nds,no,sv, (fr,it) S:NL,de,en,(da, ia)
info: http://www.let.rug.nl/~kleiweg/ls.html

[wes weston]

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.

Any ideas about this problem :-)

Ta
Nick

Nick,
Open another file and write the story of your program;
why you're writing it, what it does, roughly how it does
it, what it operates on, who uses it, what it produces,
special problems, future considerations; a general
description.

Make another file listing specific things each user
will be able to do; his action and what is produced and
in what form.

By this time you should have an idea of what the
user interface will look like; gui, command line(both),
menu(s).

All things move forward together.

Possibly; code an interface only with all the menus.

Come up with data structures; empty classes with
only documentation and maybe variable names and empty
methods.

Put this at the bottom of every py file:
if __name__ == "__main__":
pass
Most of the time of you do anything to the file, put
a test in and test it here. As new tests are done,
describe them and comment out the last one.

Pick the most risky processe(s) and design/code.
Risky meaning is it doable and will your current
concept get the job done.

Test.

Iterate.

wes

[Neil Benn]

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.

<snip>
Hello,

It's good that you are thinking of this rather than just
trying to manically write some code to see what happens. As a general
point, there is a system that you can use to help you model out your
program (taught to most computer science students). This system is
called UML (Unified Modeling Language) - I would advise getting a good
book about UML and reading through that. It's is complementary to the
XP (Extreme Programming) stuff that people are talking about.

However, be aware that some of the concepts assumed in UML don't mix
too well to the 'Pythonic' way of doing things. If you want to have a
try writing some UML here are two systems you can get - there are others
- (I can't remember the links off the top of my head) they are an
OpenSource system called 'ArgoUML' or the community edition of
'Together' from Borland. Personally I prefer Together.

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : [phone]
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[Piet]

Hello,
now my 2 cents about this topic...
1. Get a good text editor.
When you already sit in front of an empty file, this point is
apparently done ;-)
2. Get a or "the" revision control system. It is freely available for
personal use.
3. Do not start with a program that only accepts input from the
console and sends output to the console, but learn how to handle files
so that you can store the information you fed into your program and
the data you get out.
4. Don´t try to make your code as short as possible, but as readable
as possible. Don´t put too many statements in a single line. Don´t use
too many list comprehensions and stuff like that in the beginning too
frequently.
5. Document your code lines from the very beginning. Don´t leave out
any commenting of your code because in the moment you code it is just
completely clear to you what the code means, is supposed to do and how
it works. It neccessarily won´t be that clear tomorrow.
6. Don´t make your variable names too short. Give them names that
describe what they are, and try to use similar name patterns for
similar variables. Use names that can be unambigously identified by a
search pattern, so that you will find occurences of variables quickly
without too much overhead.
7. Oops, I almost forgot: get a language that can be learned quickly
so that you get your code together without too much head scratching,
but a language that lets you also use advanced concepts when you are
ripe for them. Since you are posting in comp.lang.pytho n, this is
apparently already done as well.
Have fun

Peter

[Peter Hansen]

Max M wrote:

Jp Calderone wrote:

Close the file. Open test_mykewlprog ram.py and begin writing unit
tests.
I completely agree in the value of test driven development, but for
someone writing a first program I completely disagree!

He will have to fight both programming in itself, and the test driven
development process.

I would have thought that the TDD process was *how* one would "fight
programming". Do you have a better way? All the approaches I've
seen in the past were much, much more difficult and less assured
of useful results in a reasonable time.

(Also, as a new programmer, he is unlikely to have to "fight"
TDD, since he doesn't have other approaches to try to unlearn.
I assume unlearning old habits is what you were thinking about,
because TDD itself is so simple that it's not at all hard to
actually follow the process.)
There is a big difference in learning to program, and in programming
itself.

You should simply start coding! Solve problems as you go along. The most
important thing is to allways be aware when something is repeated.
It seems to me the OP was asking *how* to "start coding". Telling
him merely to do so is not likely to help. He already knows he
has to start coding...
Dont Repeat Yourself
=============== =====

If you have written a similar piece of code 3 times, you should refactor
it into a function.

How does he get any code at all, when he doesn't know how
to start? You can't refactor what doesn't exist.

-Peter

[Peter Hansen]

Neil Benn wrote:

Nick Evans wrote:

I have been on and off learning to code ...
It's good that you are thinking of this rather than just trying
to manically write some code to see what happens. As a general point,
there is a system that you can use to help you model out your program
(taught to most computer science students). This system is called UML
(Unified Modeling Language) - I would advise getting a good book about
UML and reading through that.

Ahhh!! Run! Run, Neil, run! UML!
It's is complementary to the XP (Extreme
Programming) stuff that people are talking about.

Ahhh!!! Run away some more! UML and XP are nearly anti-thetical.
Don't even consider going there. (Well, consider it, but please
don't waste any money buying a UML book as you do. Find a few
web sites, then ... run away! It's cheaper that way.)

In my opinion, if you try to get a beginning programmer to work using
UML when he isn't even sure how to start writing code in an empty
file, you will not have a beginning programmer for long. And I
don't mean because you've just got him over that initial hump...

In another opinion of mine, if you try to get a more advanced
programmer to work using UML, you also deserve whatever you get...

-rabidly-anti-UML-ically y'rs,
Peter

[Alexander Hoffmann]

Hello,

On Tuesday 07 September 2004 01:02, Peter Hansen wrote:

Neil Benn wrote:

Nick Evans wrote:

I have been on and off learning to code ...

It's good that you are thinking of this rather than just trying
to manically write some code to see what happens. As a general point,
there is a system that you can use to help you model out your program
(taught to most computer science students). This system is called UML yes, I know ;-) (Unified Modeling Language) - I would advise getting a good book about
UML and reading through that.

Ahhh!! Run! Run, Neil, run! UML!

Please, stay calm ! I recommend you not to run because because UML is nothing
you should fear, but also forget about the UML book FOR THE MOMENT !

Please reflect on your goals. Why do you want to write programs, what are they
meant to be used for in the end ? If you want to write very small programs to
be used like shell scripts on your private Linux box, then never spend your
time with UML, extreme programming, unit tests and all that stuff.
If you plan to write rich featured applications or even deamon processes then
first lean the basic ideas of how to write code. There are lots of tutorials
and books around that help you gain success very quickly. Write some little
apps and watch them doing their job.
When you're done, then take care of how to write bigger programs. Now you
should learn how to design an application, in what parts or modules it should
be implemented and how these modules shall communicate / work together. This
is what you should utilize PARTS of UML for. I strongly recommend you to look
at static structure diagrams, use cases and time line diagrams. The other
parts of UML are only useful in theory, they take much more time to be
created than they will ever save.
Once you are familiar with basic Python programming and with application
design (e.g. UML), then the last step I recommend to become a *nearly* (who
really claims to be completely) perfect developer is to understand the
importance of testing. When you are implementing a real big application you
are lost without it. I am using unit tests and they help me very much. With
these you can test first very small parts of your application and then later
combine the test to cover more and more of the whole program. Indeed there is
no need to argue for unit testing (when writing really big applications): try
it and you will appreciate it !

Regards,
Alex

It's is complementary to the XP (Extreme
Programming) stuff that people are talking about.

Ahhh!!! Run away some more! UML and XP are nearly anti-thetical.
Don't even consider going there. (Well, consider it, but please
don't waste any money buying a UML book as you do. Find a few
web sites, then ... run away! It's cheaper that way.)

In my opinion, if you try to get a beginning programmer to work using
UML when he isn't even sure how to start writing code in an empty
file, you will not have a beginning programmer for long. And I
don't mean because you've just got him over that initial hump...

In another opinion of mine, if you try to get a more advanced
programmer to work using UML, you also deserve whatever you get...

-rabidly-anti-UML-ically y'rs,
Peter