When you get to have too much code, there are two
things you can do about it. Thing 1 is ignore the
problem and just hope it won't bite you in the ass
too much. This is also referred to as the ostrich
algorithm. It can work, but it is not
"aesthetically pleasing or, in
other words, fly". Also, it means that you are writing bad code, which will significantly decrease your enjoyment, and the whole point of this is to have fun.
Thing 2 is to break out your code into separate
files, and use those files as libraries. Libraries, in python-speak (and
in the speak of many other languages) can also be
called modules, so watch out as the two terms are
relatively interchangeable. If you have to give
them a difference, then I would say that a library
is code that you got from someone else, while a
module is something you wrote yourself.
If you would like to break out a function into a
different file, just create a new file, we'll call
it monkey, and put your functions in
there. Then, when you want to use functions or
variables that are defined in that file, simply copy
the file to your current directory (or to any
directory in your python search path, but if you
don't get that, don't worry about it). Then, when
you want to use it in another file in that
directory, just type import monkey.
All the functions, etc in that file are then
available for your pleasure; to access one of them,
for example the peelBanana() function,
now all you have to do is type
monkey.peelBanana().
This makes it extremely easy to break out functions
that are easily associated in some sort of logical
grouping, and put each group in a separate file.
Then, there won't be nearly so many proper nouns
floating around to give you trouble (in CS terms: you won't have such a cluttered
namespace), the files themselves will be smaller,
the programs internal structure of
what-depends-on-what should be more obvious (the
dependency graph won't be as complex), there won't
be such a large propensity for things to break
(you'll have a low degree of inter-module
dependence), and everything will be easy to maintain
as time moves on.
After you've been coding for a while you'll discover
that the challenge is not writing the code in the
first place (although that has a special high all
its own) the challenge is writing something that you
can go back to and extend in the future. Solving
any problem poorly is relatively easy, but solving
it in such a way that it will be extensible,
generalizable, and readable is something that only
comes through practice and a lot of
elbow grease.
The main idea here is that not all of your functions
need to know about everything, and allowing them to
know about and touch everything is just inviting bad
behavior. Therefore, if you divide them up into
logical units that have no way of knowing about each
other, good habits will be reinforced and you will
go home happy, both today and tomorrow.
<< | Learn to Program | >>