note
tilly
Quite a few areas of computer science are devoted to parts
of this question. Every good programmer has read multiple
books on it. This is not a simple topic.<P>
You might ask how much could really be said about this. The
answer is that you would be astounded.<P>
A few random topics are how you should name variables
(chapter 1 of the Camel has some interesting advice for
that), how much to indent (anything from 2-4 works as
long as you are consistent, Larry Wall uses 4), to how
long a function should be (my estimate is that I average
about 10 lines, a general rule of thumb is that 50 lines or
one screen should be a max), how do you give feedback (it
turns out that code reviews are cost effective just in
terms of bugs discovered), management techniques,
programming methodologies... You name it, it has been
studied and frequently useful information is known.<P>
The importance of the topic can be seen in Perl by looking
at how many functions exist for little purpose other than to
help people keep programs managable. A short list includes
[bless], [local], [my], [package], [require], [sub] and
[use]. Don't forget the pragmas [strict], [vars] and
[diagnostics]. (And turn warnings on as well!) In
addition Perl has quite a bit of syntax (think comments,
POD, flexible quoting, etc) that is geared towards letting you
say things in a natural way. (There is a school of thought
that says that making the gap between how you think about
a problem and how you say it small is good. Perl tends
this way. There is another that says it is good to always
say things in a consistent way. The truth is somewhere in
the middle, it depends on the characteristics of the product
and developers whether flexibility hurts or helps.) Getting
familiar with and using those tools on a regular basis
will go a long ways towards helping keep your script
managable.<P>
But now I should reveal a dirty little secret.<P>
We do all this, and we still fail. Individually and as a
whole, the programming industry routinely fails in both
insignificant and spectacular ways. The central problem
of programming is the same today as it was 50 years ago.
Namely keeping in control of the complexity of software.
There is no need to be cynical about research into this problem, we have learned a lot over the years, and we can handle much harder problems now. Your
script is quite managable. But still our basic barrier is in our
ability to keep track of what the computer has been told
to do. We can move where that barrier is, but not stop it
from being a problem in the end.<P>
From of this research there is a key insight that comes
up again and again. That is the value of modularity. You
really want to take problems, and break them up into smaller
problems, then produce solutions to each smaller problem,
and put the components back together. It is important that
each component be independent of the others. This is true
whether your components are functions, modules, etc. As a
random instance [Dominus] has a good
[http://perl.plover.com/varvarname3.html|rant] about why
this matters. Indeed most of the functions and pragmas that
I listed above in some way serve to make it possible to
isolate components, or to help you verify that things have
been properly separated.<P>
If you want good places to pick up more advice on this
topic, [id://163] gives links for a number of books,
including both Code Complete and The Pragmatic Programmer.
Most good Perl books will give practical demonstrations
of how to do it. And, of course, look around at this
site. There is a lot of good advice, and many monks offer links
to even more. I would personally recommend visiting the
home nodes for [Dominus], [merlyn] and [chromatic] for a start.<P>
(Next up, how to write a long post without meaning to!)<P>
<B>UPDATE</B><BR>
Edited to fix minor grammar mistakes.
62678
62678