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 | >>

Log in or registerto write something here or to contact authors.